I'm re-sending this as I had a problem with my webmail and the formatting got 
messed up for the text view.

We have inconsistencies on how dates are presented and the formats that are 
acceptable. This only includes inconsistent handling of the time zone offset. 
Fixing these would mean a change to the respective bundles to support java 8 by 
default or to make changes to what the current default format is.

The problem:
Prior to Java 8 there was no out of the box way to support the parsing of a 
String into a Date that would keep the time zone offset. The java.util.Date 
object does not contain information about the offset and assumes everything 
from a UTC. The Calendar object does maintain a time zone but uses the system 
time zone as a default.

There is a Standard for time strings called ISO-8601 which is used by the JCR, 
there is a utility class used by several bundles that utilizes this class and 
this will create a Calendar object with the correct time zone offset. However 
not all bundles use this.

Current Areas of Concern:
Content Loader with  a JSON payload, only recognizes a value as a Date if it 
uses the ISO-8601 format, however the Content Loader uses the java 
SimpleDateFormatter instead of the ISO8601 util so time zone offset it lost.

Content Parser recognizes ISO-8601 and an ECMA format, ECMA format does not 
support offset.

Form Post handling with a TypeHint of Date will recognize multiple formats 
including ISO-8601, will only keep the time zone offset with the ISO-8601 
format.

Default JSON handler is returning dates as an ECMA format, not as ISO-8601 the 
ECMA format is a format that was primarily used by browsers. This format is not 
the default for browsers anymore, the default format for browsers is the 
ISO-8601 format.

Solutions:
The easiest way of parsing date strings and keeping offsets would be to use the 
java.time package from java 8 which would upgrade the dependencies in those 
bundles mentioned.

Other options would be to have any usage of the ISO-8601 format be parsed with 
the ISO8601 utility class and to have ALL exports of Date Strings use the 8601 
format as default. We could then state that if you want to keep the offset use 
the standard date string format. That would require a change in the default 
JSON handler.

Other options and opinions would be great.

- Jason

Reply via email to