[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