[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