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

[Richard Norman]

Again the important thing is what are you trying to capture.. The =
instant in
time (the relativity issue) or the time at the location.

If the moment in time is important, then doing the time translation is
correct in that at that moment, the time there is a different time here.

If the time at the location is the important thing, then you need a
transparent medium like a string or individual integer values or tick
values.

That is the way handling time should be unless the time value had a
specification that the time sent was important and not the moment. If =
you
send a time, then the moment is important. If you send time as text then =
the
value is important...

All relative in what you want...  But a way to specify the moment or =
value
would be good.

But I don't believe it is broken..

Richard Norman
Web/Application Developer


-----Original Message-----
From: A Rafael D Teixeira [mailto:rafaelteixeirabr@hotmail.com]=20
Sent: Saturday, June 28, 2003 8:25 AM
To: Jazzynupe@sbcglobal.net; mono-list@lists.ximian.com
Subject: Re: [Mono-list] A big (MS created) flaw in DateTime that =
surfaces
in Web Services


>From: "Richard Norman" <Jazzynupe@sbcglobal.net>

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

>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=20
>+ 2 =3D -6) take
>away 6 hours from the time......

Yes, but the problem is: when calling a Web Service (or remoting), we =
want=20
it to be a transparent medium ie it should not change the data it is=20
carrying.

>So if I follow your example,
>
>  27/6/2003 14:00:00-6  sent to a time zone with +1 should become the=20
>following...
>
>(+1)-(-6) becomes +1+6=3D7
>
>So you add 7 hours to the time which then becomes 27/6/2003 21:00:00+1
>
>So if that is correct, and that is how it is handled internally, then=20
>we don't have a problem I believe

We still have 2 problems: MinValue and MaxValue drifting, and Daylight=20
Savings non-simetric behavior.

Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001

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