[Mulgara-dev] XSD Date/Time Corruption reproducible
Andrae Muys
andrae at netymon.com
Sat Jan 27 01:07:15 UTC 2007
On 27/01/2007, at 3:59 AM, Paul Gearon wrote:
> To avoid this ambiguity, I think we need the option to include the
> timezone when printing.
> The best way to set this would be via a system property. My
> proposal is the following:
> - If no property is set, then print the time in the current
> timezone with no timezone info (ie. what we do now).
> - If the property is set to "local" then use the system timezone,
> and print it. In my case this would append -06:00
> - If the property is set to "Z" or "UTC" then print out Zulu time
> with "Z" on the end.
> - If the property is set to +/-hh:mm then print with that timezone.
> - If the property is set to anything else, then log a warning, and
> print Zulu time.
>
> Printing in any timezone should be safe, since it will always get
> parsed as the correct absolute value. That's why I suggest
> printing Zulu time as the last option.
Actually in discussion last night it occurred to me that this isn't
going to work either. This problem arose because localtime is not
continuous. The above proposal doesn't work because localtime isn't
monotonic either. Specifically there is no localtime lexical form
for the last hour of DST - java assumes standard-time for ambiguous
timestamps.
I think we always have to use timezones, ie. option 1. isn't really
an option.
Moreover we also do need to think about adding a localtime datatype -
one that actually stores a date/time rather than a timestamp. This
is important for issues such as calendar applications and event
management where the location/timezone is stored independently of the
date/time and the value cannot be represented as a time_t. For now
users who need to do this can reify their dates, but it would be nice
to support them natively.
Andrae
--
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd
More information about the Mulgara-dev
mailing list