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
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
