Literal normalization about tck HOT 2 CLOSED

My concern about adopting a normal format is that the spec allows all those format, and the code must be tested against all those possibilities. In this particular case, if the Date was constructed in time zone "Europe/Paris" then any subsequent conversion back to string MUST use that designation. Yes, it is true that Java (standard) dates might produce a numeric offset, but that is simply an indication that Java does not support the DMN dates exactly.

I am afraid that if we agreed to always use the "Europe/Paris" format for string, we would miss out on testing with "01:00" format, and would not be testing the entire set of cases.

Of course, DMN never guarantees that all string representations of a moment in time are gong to be the same. It sounds like you are trying to make a shortcut by comparing strings when you should probably be making a proper comparison that works according the spec. It is true that "Z" means the same as "+00:00" and I don't off hand know if "-00:00" is allowed or not, but that might be another equivalent value. You comparison of a date with "Z" must compare equal to "+00:00" regardless of how the stringified form looks.

If you can expand this with a REAL paradox, something that would conform to the spec, but for which we can not write a reliable test, then we can consider this further.

from tck.

This has been addressed in the RTF

from tck.