[Mulgara-dev] XSD Date/Time Corruption reproducible

Paul Gearon gearon at ieee.org
Fri Jan 26 17:59:31 UTC 2007


Hi all,

Last night I decided to be nice to the Mouse Pusher guys, and debug their
date library for them.  This led to some interesting revelations.  This took
me a while to get through, so I'm going to make you go through it with me.
:-)

On 1/23/07, David Moll <DMoll at viewpointusa.com> wrote:
>
> Somehow, T02:56:00 becomes T03:56:00.


The significant thing here is that the date/time is:
April 26, 1981, 02:56:00

Andrae helped me discover that this is actually at the transition time for
daylight savings in the USA.  That means that there was *no* 2:56am.  The
time went 01:59:59.999 -> 03:00:00.000.  So the observed behavior is correct
for times in the USA.

(David, didn't you have other time variations?  Can you post them so I can
check those out please?)

However, this behavior will be problematic for anyone inputting foreign data
into a USA system.  In this case the timezone will have to be set
explicitly.  We don't parse for timezones yet, even though these are part of
the XSD spec.  Date/times with a timezone either have a "Z" on the end (Zulu
- for UTC), or else they have a +/- hh:mm.  See
http://www.w3.org/TR/xmlschema-2/#dateTime-lexical-representation for the
details.  We will need to add this option into the SPDateTimeImpl code.

Brian also raised the question of how date/time data should be printed out.
Even though the data is stored in canonical form, SPDateTimeImpl currently
uses the client's timezone for printing out.  That wouldn't be so bad,
except that the timezone is *not* printed.  This could lead to ambiguity in
some cases.

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.

Regards,
Paul Gearon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20070126/e7089063/attachment.htm>


More information about the Mulgara-dev mailing list