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 a generic *DATE* value, largely ignoring the time. In fact, the application made no distinction between a DateTime value being used as a timestamp, and a "Date Stamp" value.
Everything worked wonderfully until we had to start deployment in time zones other than US Pacific Time!
The bottom line was that TimeStamps should be transmitted as the raw data you are seeing, as the time of '1/1/2003 3:00am' in New York *IS* '1/1/2003 12:00am' in California.
However, storing, transmitting things like Birthdate, DeathDate, etc, etc, where Time Zones are irrelevant calls for the use of a different [Serializable] base type. The quick and easy solution is to store the 'DateStamp' value as a string, and create properties insert/extract as DateTime, or provide implicit operators to handle the casting for you.
Morale of the story: If the value you are transmitting doesn't care 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 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)= -8 + 2 = -6) take away 6 hours from the time......
�
So if I follow your example,
�
�27/6/2003 14:00:00-6� sent to a time zone with +1�should become�the following...
�
(+1)-(-6) becomes +1+6=7
�
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 we don't have a problem I believe
�
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... :-)
�
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.
�
Could someone check this out?� I don't have all the tools here at home to test this.
�
Richard Norman
Web/Application Developer
�
*****************Original Messages**************************
�
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
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
