[Mulgara-dev] XSD Date/Time Corruption reproducible

Paul Gearon gearon at ieee.org
Sat Jan 27 06:29:20 UTC 2007


On Jan 26, 2007, at 7:07 PM, Andrae Muys wrote:

>
> 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.

I disagree.  From a string representational point of view (which is  
what toString() is all about) then the ambiguous time is just fine.   
That's EXACTLY what people see.  Internally the times are just fine,  
and the system knows that 1:30am the first time through is actually  
earlier than 1:15am the second time through.  It just get printed in  
a funny way for people.  But it's *supposed* to.

If it's important that it get printed in an unambiguous way, then we  
provide the option for it.

> 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.

I'm reluctant to add any datatype that is not in XSD.  For a start,  
what is the datatype URL?  It won't be standard RDF.

Paul



More information about the Mulgara-dev mailing list