[Mono-list] A big (MS created) flaw in DateTime that surfaces in Web
A Rafael D Teixeira
Fri, 27 Jun 2003 19:10:47 -0300
>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
>27/6/2003 07:00:00 (where 7 = 14 - (+1) + (-6)). If this date goes back
>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.
You are missing the point:
Here is an example you can possibly test for yourself.
I have two DateTimes one containing 1998/10/16T00:00:00000 (a friday) and
the other 1998/10/19T00:00:00000 (a monday) both without time zone
information and both extracted from a database.
The server is in a time zone so that it decides to encode them as:
1998/10/16T00:00:00000-03:00 (normal period of the year) and
1998/10/19T00:00:00000-02:00 (because it crossed into a daylight savings
The problem is that the client is theoretically in the same time zone but it
ends parsing it back as follow:
1998/10/18T23:00:00000 (became sunday 11pm). THAT IS THE PROBLEM MANIFESTING
Even if I'm wrong about both machines staying in the same time zone, I don't
want the information to change because in truth the server may be housed in
São Paulo, but this data has many sources around the globe (Tokyo and New
York, for example), and Dates and Times are already universalized in the
database and are to be shown as stored not adjusted.
>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
>can always include the UTC offset as an extra parameter.
That is what I want: It MUST NOT be adjusted from the insuficient
information the infraestructure has.
>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.
That is the problem again. Server and client location can't interfere in
transmitting data. If I have a DateTime.MinValue at one end IT MUST STILL BE
A DateTime.MinValue at the other. What we are saying is that this channel is
not transparent, that is for me a BUG.
> > 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.
Yes, my database contains data from around the globe, but all of it is
normalized to a single reference location.
>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.
I only want to have control of the process so that I can say, when needed,
that I want a datetime to pass transparently from one end to the other.
Mono Hacker since 16 Jul 2001
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*