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 bundle to support java 8 by default or 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
