[Mono-list] A big (MS created) flaw in DateTime that surfaces in Web Services
Richard Norman
Jazzynupe@sbcglobal.net
Sat, 28 Jun 2003 01:38:56 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_0003_01C33D16.0A5281A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Now I may be wrong in this too, but isn't the offset used as a marker to
indicate the time zone?
=20
So the time shown is 2 hours behind the GMT... so if you are going from =
say
-2 to a -8 time zone, you would take the destination time zone and =
subtract
the source and add those hours to the time ( take -8-(-2)=3D -8 + 2 =3D =
-6) take
away 6 hours from the time......
=20
So if I follow your example,
=20
27/6/2003 14:00:00-6 sent to a time zone with +1 should become the
following...
=20
(+1)-(-6) becomes +1+6=3D7
=20
So you add 7 hours to the time which then becomes 27/6/2003 21:00:00+1
=20
So if that is correct, and that is how it is handled internally, then we
don't have a problem I believe
=20
However if you are saying that you want to send a datetime without =
changes
to another potentially different time zone, why not send it as another =
type
in transmission so it is not interpreted. That might be one way to do =
it...
Time information should be universal and the time one place should =
coincide
with the same moment in another place. Hence I believe it is not a true =
but
but a exercise in relativity... :-)
=20
Do you want the time it is there or the time it is here. if you want the
time there, then you must either send date time and create a thread with =
the
same time zone information, or send something like a string that is not
interpreted and convert once it is received. If you want the instant, =
then
the conversion outlined above and previously is correct.
=20
Could someone check this out? I don't have all the tools here at home =
to
test this.
=20
Richard Norman
Web/Application Developer
=20
*****************Original Messages**************************
=20
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 =
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=20
>example, lets say that there is a server A in GMT+1 timezone thats=20
>makes a call to a server B in GMT-6 timezone. The call includes the=20
>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 =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 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=20
>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=20
the other 1998/10/19T00:00:00000 (a monday) both without time zone=20
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=20
S=E3o Paulo, but this data has many sources around the globe (Tokyo and =
New=20
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=20
>ticks, so don't include the UTC offset. When such a date is serialized=20
>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=20
information the infraestructure has.
=20
>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=20
>be careful to use for example DateTime.MinValue as a marker for null=20
>dates, because this value can change if the date is deserialized in a=20
>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=20
> > Ticks member of the DateTime, but this is a larger issue with=20
> > broader implications.
>
>This does not solve the issue, unless you work always with the same=20
>timezone. Ticks are also relative to the time zone.
Yes, my database contains data from around the globe, but all of it is=20
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=20
>already does it, BinaryFormatter does not.
I only want to have control of the process so that I can say, when =
needed,=20
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
------=_NextPart_000_0003_01C33D16.0A5281A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D201141908-28062003>Now I may be wrong in this too, =
but isn't=20
the offset used as a marker to indicate the time zone?</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>So the time shown is 2 hours =
behind the=20
GMT... so if you are going from say -2 to a -8 time zone, you =
would take=20
the destination time zone and subtract the source and add those hours to =
the=20
time ( take -8-(-2)=3D -8 + 2 =3D -6) take away 6 hours from the=20
time......</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>So if I follow your =
example,</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003> 27/6/2003 14:00:00-6 =
sent to a=20
time zone with +1 should become the following...</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>(+1)-(-6) becomes =
+1+6=3D7</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>So you add 7 hours to the time =
which then=20
becomes 27/6/2003 21:00:00+1</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>So if that is correct, and that is =
how it is=20
handled internally, then we don't have a problem I believe</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>However if you are saying that you =
want to=20
send a datetime without changes to another potentially different time =
zone, why=20
not send it as another type in transmission so it is not interpreted. =
That might=20
be one way to do it... Time information should be universal and the time =
one=20
place should coincide with the same moment in another place. Hence I =
believe it=20
is not a true but but a exercise in relativity... :-)</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>Do you want the time it is there =
or the time=20
it is here. if you want the time there, then you must either send date =
time and=20
create a thread with the same time zone information, or send something =
like a=20
string that is not interpreted and convert once it is received. If =
you=20
want the instant, then the conversion outlined above and previously is=20
correct.</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>Could someone check this =
out? I don't=20
have all the tools here at home to test this.</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>Richard Norman</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003>Web/Application =
Developer</SPAN></DIV>
<DIV><SPAN class=3D201141908-28062003></SPAN> </DIV>
<DIV><SPAN class=3D201141908-28062003>*****************Original=20
Messages**************************</SPAN></DIV>
<DIV> </DIV>
<DIV>
<P>Message: 12</P>
<P>From: "A Rafael D Teixeira" <rafaelteixeirabr@hotmail.com></P>
<P>To: lluis@ideary.com, mono-list@lists.ximian.com</P>
<P>Subject: Re: [Mono-list] A big (MS created) flaw in DateTime that =
surfaces in=20
Web Services</P>
<P>Date: Fri, 27 Jun 2003 19:10:47 -0300</P>
<P>Hi Lluis,</P>
<P>>Hmm. Maybe I'm missing something, but I don't see the problem. =
For </P>
<P>>example, lets say that there is a server A in GMT+1 timezone =
thats </P>
<P>>makes a call to a server B in GMT-6 timezone. The call includes =
the </P>
<P>>date 27/6/2003 14:00:00. The XmlSerializer in server A will =
format this=20
</P>
<P>>date as 27/6/2003T14:00:00.0000000+01:00. The server B will =
deserialize=20
</P>
<P>>this date as 27/6/2003 07:00:00 (where 7 =3D 14 - (+1) + (-6)). =
If this=20
</P>
<P>>date goes back from</P>
<P>>server B to server A, server B will serialize</P>
<P>>27/6/2003T07:00:00.0000000-06:00, and server A will get again=20
27/6/2003</P>
<P>>14:00:00 (where 14 =3D 7 - (-6) + 1)</P>
<P>></P>
<P>>BTW, this didn't work a couple of days ago, I just commited that =
fixes=20
</P>
<P>>it.</P>
<P>You are missing the point:</P>
<P>Here is an example you can possibly test for yourself.</P>
<P>I have two DateTimes one containing 1998/10/16T00:00:00000 (a friday) =
and=20
</P>
<P>the other 1998/10/19T00:00:00000 (a monday) both without time zone =
</P>
<P>information and both extracted from a database.</P>
<P>The server is in a time zone so that it decides to encode them =
as:</P>
<P>1998/10/16T00:00:00000-03:00 (normal period of the year) and</P>
<P>1998/10/19T00:00:00000-02:00 (because it crossed into a daylight =
savings </P>
<P>period)</P>
<P>The problem is that the client is theoretically in the same time zone =
but it=20
</P>
<P>ends parsing it back as follow:</P>
<P>1998/10/16T00:00:00000</P>
<P>1998/10/18T23:00:00000 (became sunday 11pm). THAT IS THE PROBLEM =
MANIFESTING=20
</P>
<P>ITSELF.</P>
<P>Even if I'm wrong about both machines staying in the same time zone, =
I don't=20
</P>
<P>want the information to change because in truth the server may be =
housed in=20
</P>
<P>S=E3o Paulo, but this data has many sources around the globe (Tokyo =
and New=20
</P>
<P>York, for example), and Dates and Times are already universalized in =
the </P>
<P>database and are to be shown as stored not adjusted.</P>
<P>></P>
<P>>In Remoting, there may be a problem, because DateTime is =
serialized as=20
</P>
<P>>ticks, so don't include the UTC offset. When such a date is =
serialized=20
</P>
<P>>in the destination sever there is no way to know the original =
timezone.=20
</P>
<P>>But you can always include the UTC offset as an extra =
parameter.</P>
<P>That is what I want: It MUST NOT be adjusted from the insuficient =
</P>
<P>information the infraestructure has.</P>
<P> </P>
<P>>Yes, that's another problem. I've partially removed some of this =
checks=20
</P>
<P>>to match MS.NET behavior, and it works better now. However you =
have to=20
</P>
<P>>be careful to use for example DateTime.MinValue as a marker for =
null </P>
<P>>dates, because this value can change if the date is deserialized =
in a=20
</P>
<P>>server that has a different timezone.</P>
<P>That is the problem again. Server and client location can't interfere =
in </P>
<P>transmitting data. If I have a DateTime.MinValue at one end IT MUST =
STILL BE=20
</P>
<P>A DateTime.MinValue at the other. What we are saying is that this =
channel is=20
</P>
<P>not transparent, that is for me a BUG.</P>
<P>></P>
<P>> > For my application I will just avoid the issue by =
serializing the=20
</P>
<P>> > Ticks member of the DateTime, but this is a larger issue =
with </P>
<P>> > broader implications.</P>
<P>></P>
<P>>This does not solve the issue, unless you work always with the =
same </P>
<P>>timezone. Ticks are also relative to the time zone.</P>
<P>Yes, my database contains data from around the globe, but all of it =
is </P>
<P>normalized to a single reference location.</P>
<P>>I dont find necessary to extend or change DateTime to include UTC =
info.=20
</P>
<P>>It is enough to include it when a data is serialized. =
XmlSerializer </P>
<P>>already does it, BinaryFormatter does not.</P>
<P>I only want to have control of the process so that I can say, when =
needed,=20
</P>
<P>that I want a datetime to pass transparently from one end to the =
other.</P>
<P>Best regards,</P>
<P>Rafael Teixeira</P>
<P>Brazilian Polymath</P>
<P>Mono Hacker since 16 Jul 2001</P></DIV></BODY></HTML>
------=_NextPart_000_0003_01C33D16.0A5281A0--