[Mono-list] A big (MS created) flaw in DateTime that surfaces in Web Services

[Lluis Sanchez]

Hi Rafael!

> Lluis, how do we handle serializing DateTime over XML (in Remoting and on
> Web Services)?

In the same way as MS does :-)

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

Hmm. Maybe I'm missing something, but I don't see the problem. For example,
lets say that there is a server A in GMT+1 timezone thats makes a call to a
server B in GMT-6 timezone. The call includes the date 27/6/2003 14:00:00.
The XmlSerializer in server A will format this date as
27/6/2003T14:00:00.0000000+01:00. The server B will deserialize this date as
27/6/2003 07:00:00 (where 7 = 14 - (+1) + (-6)). If this date goes back from
server B to server A, server B will serialize
27/6/2003T07:00:00.0000000-06:00, and server A will get again 27/6/2003
14:00:00 (where 14 = 7 - (-6) + 1)

BTW, this didn't work a couple of days ago, I just commited that fixes it.

In Remoting, there may be a problem, because DateTime is serialized as
ticks, so don't include the UTC offset. When such a date is serialized in
the destination sever there is no way to know the original timezone. But you
can always include the UTC offset as an extra parameter.

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

Yes, that's another problem. I've partially removed some of this checks to
match MS.NET behavior, and it works better now. However you have to be
careful to use for example DateTime.MinValue as a marker for null dates,
because this value can change if the date is deserialized in a server that
has a different timezone.

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

This does not solve the issue, unless you work always with the same
timezone. Ticks are also relative to the time zone.

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

I dont find necessary to extend or change DateTime to include UTC info. It
is enough to include it when a data is serialized. XmlSerializer already
does it, BinaryFormatter does not.

- Lluis