Message: 12
From: "A Rafael D Teixeira" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Mono-list] A big (MS created) flaw in DateTime that surfaces in Web Services
Date: Fri, 27 Jun 2003 19:10:47 -0300
Hi Lluis,
>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.
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
period)
The problem is that the client is theoretically in the same time zone but it
ends parsing it back as follow:
1998/10/16T00:00:00000
1998/10/18T23:00:00000 (became sunday 11pm). THAT IS THE PROBLEM MANIFESTING
ITSELF.
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 you 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.
Best regards,
Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
