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

[Steve Mentzer]

I ran into a similar issue about 9 months ago when re-architecting
a COM/VB based client/server back-end in c# and .net.

In a nutshell, we were using the SQL Datetime, VB Date, double, etc as=20=

a generic *DATE* value, largely ignoring the time. In fact, the=20
application made no distinction between a DateTime value being used as=20=

a timestamp, and a "Date Stamp" value.

Everything worked wonderfully until we had to start deployment in time=20=

zones other than US Pacific Time!

The bottom line was that TimeStamps should be transmitted as the raw=20
data you are seeing, as the time of '1/1/2003 3:00am' in New York *IS*=20=

'1/1/2003 12:00am' in California.

However, storing, transmitting things like Birthdate, DeathDate, etc,=20
etc, where Time Zones are irrelevant calls for the use of a different=20
[Serializable] base type. The quick and easy solution is to store the=20
'DateStamp' value as a string, and create properties insert/extract as=20=

DateTime, or provide implicit operators to handle the casting for you.

Morale of the story: If the value you are transmitting doesn't care=20
about 'time', don't use DateTime.


On Saturday, June 28, 2003, at 01:38 AM, Richard Norman wrote:

> Now I may be wrong in this too, but isn't the offset used as a marker=20=

> to indicate the time zone?
> =A0
> So the time shown is 2 hours behind the GMT... so if you are going=20
> from say -2 to a -8 time zone, you would=A0 take the destination time=20=

> zone and subtract the source and add those hours to the time ( take=20
> -8-(-2)=3D -8 + 2 =3D -6) take away 6 hours from the time......
> =A0
> So if I follow your example,
> =A0
> =A027/6/2003 14:00:00-6=A0 sent to a time zone with +1=A0should =
become=A0the=20
> following...
> =A0
> (+1)-(-6) becomes +1+6=3D7
> =A0
> So you add 7 hours to the time which then becomes 27/6/2003 21:00:00+1
> =A0
> So if that is correct, and that is how it is handled internally, then=20=

> we don't have a problem I believe
> =A0
> However if you are saying that you want to send a datetime without=20
> changes to another potentially different time zone, why not send it as=20=

> another type in transmission so it is not interpreted. That might be=20=

> one way to do it... Time information should be universal and the time=20=

> one place should coincide with the same moment in another place. Hence=20=

> I believe it is not a true but but a exercise in relativity... :-)
> =A0
> Do you want the time it is there or the time it is here. if you want=20=

> the time there, then you must either send date time and create a=20
> thread with the same time zone information, or send something like a=20=

> string that is not interpreted and convert once it is received.=A0 If=20=

> you want the instant, then the conversion outlined above and=20
> previously is correct.
> =A0
> Could someone check this out?=A0 I don't have all the tools here at =
home=20
> to test this.
> =A0
> Richard Norman
> Web/Application Developer
> =A0
> *****************Original Messages**************************
> =A0
> Message: 12
>
> From: "A Rafael D Teixeira" <rafaelteixeirabr@hotmail.com>
>
> To: lluis@ideary.com, mono-list@lists.ximian.com
>
> Subject: Re: [Mono-list] A big (MS created) flaw in DateTime that=20
> 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=20
> this
>
> >date as 27/6/2003T14:00:00.0000000+01:00. The server B will=20
> deserialize
>
> >this date as 27/6/2003 07:00:00 (where 7 =3D 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=20
> 27/6/2003
>
> >14:00:00 (where 14 =3D 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)=20=

> 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=20
> savings
>
> period)
>
> The problem is that the client is theoretically in the same time zone=20=

> 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=20
> MANIFESTING
>
> ITSELF.
>
> Even if I'm wrong about both machines staying in the same time zone, I=20=

> don't
>
> want the information to change because in truth the server may be=20
> housed in
>
> S=E3o Paulo, but this data has many sources around the globe (Tokyo =
and=20
> New
>
> York, for example), and Dates and Times are already universalized in=20=

> 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=20
> 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.
>
> =A0
>
> >Yes, that's another problem. I've partially removed some of this=20
> 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=20=

> in
>
> transmitting data. If I have a DateTime.MinValue at one end IT MUST=20
> STILL BE
>
> A DateTime.MinValue at the other. What we are saying is that this=20
> 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=20
> 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=20
> 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
>