hello jason. thanks for this comprehensive summary.
in my opinion for the long run the best solution is to use ISO-8601 for all locations and deprecated the ECMA format and discourage usage of it (but keep it where it's parsed for backward compatibility). in this way we have two open points: 1. Content Loader supports ISO-8601, but does not correctly handle the timezones. this can be fixed by using the jackrabbit util class used in the other places already. we should create a bug ticket and fix it right away. 2. the only real problematic place is the GET servlet/Default JSON handler which currently outputs dates in ECMA by default. we could change this easily, but this will break backwards compatibility of code relying on it's output. in a very central piece of code. once we are on java 8 (you opened a separate thread for this) we can fix the ECMA parsing support easily. and alternative for java 7 would probably be to use a thirdparty library like joda-time (have not checked if this really solves this) - but this would mean an additionally dependency in the starter/launchpad. stefan >-----Original Message----- >From: Jason E Bailey [mailto:[email protected]] >Sent: Wednesday, April 18, 2018 6:20 PM >To: [email protected] >Subject: [Discussion] Date handling inconsistencies - resend > >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
