[Mono-list] A big (MS created) flaw in DateTime that surfaces in Web Services
A Rafael D Teixeira
rafaelteixeirabr@hotmail.com
Fri, 27 Jun 2003 00:03:40 -0300
Lluis, how do we handle serializing DateTime over XML (in Remoting and on
Web Services)?
First some background:
The DateTime struct just keeps date and time information without keeping any
time zone information, you are supposed to use ToLocalTime() and
ToUniversalTime() to adjust it by the machine's time zone info.
This is fine for many situations where you can keep a tab on how time zone
info influences the process.
But this is broken for Web Services, where it is mandatory to use full time
information when serializing it to xml and back. As time zone information
isn't present on DateTime, MS' implementation just gets the machine set time
zone and adds it to the data. It even corrects for daylight savings in
historical data what brings a bunch of problems for itself (at least in
Brazil daylight savings policies vary wildly from year to year).
At the other end the local time zone is subtracted from it. End result:
DateTime data that may be totally unrelated to the machines location (and
therefore time zones) gets displaced in time when transmitted by Web
Services.
I realized this the hard way: in my application part of the historical data
available only for workdays started to move to sundays over the wire, and
oddly, only for the daylight savings period.
Also when using DateTime.MaxValue as a value for parameters in calls,
exceptions about exceeding the MaxTicks value started to bounce from the
server.
For my application I will just avoid the issue by serializing the Ticks
member of the DateTime, but this is a larger issue with broader
implications.
Miguel, think of all time-related information being displaced on SourceGear
Vault's web services...
I see some possibilities:
1 - We can talk to ECMA and MS, to expand DateTime, but that would play
havoc by breaking binary compatibility. Remember, DateTime is a struct and
as such a value type.
2 - We can create Mono.DateTime or propose to ECMA an
System.UniversalDateTime. But only new or revised code would benefit from
it.
3 - We can serialize DateTime over XML differently: A) we can always append
a Z to arbitrarily zone it on GMT or B) as XML Schema cites the time zone
information as optional we can just leave it out. That may play bad with
broader interoperability, however.
4 - We can give more control of the xml serialization to the programmer. See
the DataType member of the Xml{whatever}Attribute family of attributes for
something almost there. Again only new or revised code would benefit.
Summarizing: I think that it was an oversight of MS, not to put time zone
information inside the DateTime struct, and it rears it's ugly head now on
web services.
Happy Solutions,
Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963