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

[A Rafael D Teixeira]

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

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail