ISODate UTC timezone fixes

[jodygarnett]

• Fix ISODate parsing to respect use of Z suffix to indicate UTC timezone
• Document ISODate constructor use of milliseconds against UTC timezone

For more information see #5016

[jodygarnett]

This change identified some inconsistencies with ISODate constructors:

• ISODate( milliseconds ) is expected to be in UTC (or GMT)
• ISODate( milliseconds, shortDate ) use the current local timezone

As an example new ISODate( new ISODate(System.currentTimeMillis()) ) produces an ISODate in UTC timezone.

I am confident in this fix as many java classes (System,Date) work with a definition of:

The number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this date.

[jodygarnett]

Discussion:

• Q: Should these two methods be consistent in their use of either UTC or Local timezone?
• Q: Does JPA persistence assume either UTC or Locale timezone?

[jodygarnett]

Thanks @ianwallen I believe I have addressed your feedback.

[juanluisrp]

• Does JPA persistence assume either UTC or Locale timezone

Currently in the database dates don't contain timezone/offset so they are interpreted in the server local time when parsed by ISODate(String isoDate) constructor.

[jodygarnett]

Thanks @juanluisrp, so we may of identified an additional QA activity in addition to this timezone consistency across the ISODate API - reporting as a separate feature request (#5040) rather than hold up this PR.

[jodygarnett]

Currently in the database dates don't contain timezone/offset so they are interpreted in the server local time when parsed by ISODate(String isoDate) constructor.

To reply directly, this the ISODate(String isoDate) constructor is unchanged, so ISODates created by JPA are fine.