[Discussion] Date handling inconsistencies

[Jason E Bailey <je...@apache.org>]

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