Strange DateTime Problem

[Looch]

All,

I'm using a WinForm app that calls methods on a remotable object. The
app server hosting the object is in New York. Using the same exact
application, a Sql Server 2005 datetime column's info is being
displayed as '3/25/2008' in California and '3/26/2008' in New York
(outside the LAN) where the data in the column is '3/26/2008 12:00:00
AM' (I'm converting the to the short date format in the app code). I
can get the California app to display the correct short date if I edit
the date in Sql Server to a time later in the day (i.e. '3/26/2008
10:00:00 AM'). What's the deal? Time zones?? Can't be...

Thanks

[Jon Slaughter]

"Looch" <lu**********@yahoo.comwrote in message
news:e3**********************************@59g2000h sb.googlegroups.com...

All,

I'm using a WinForm app that calls methods on a remotable object. The
app server hosting the object is in New York. Using the same exact
application, a Sql Server 2005 datetime column's info is being
displayed as '3/25/2008' in California and '3/26/2008' in New York
(outside the LAN) where the data in the column is '3/26/2008 12:00:00
AM' (I'm converting the to the short date format in the app code). I
can get the California app to display the correct short date if I edit
the date in Sql Server to a time later in the day (i.e. '3/26/2008
10:00:00 AM'). What's the deal? Time zones?? Can't be...

Try DateTimeOffset?

[Looch]

Thanks for the quick responses.

I'm certainly not disagreeing but I don't get it. The remotable object
method in question selects four fields from the db (one being the
datetime type mentioned above), uses those four items to set
MyObject's four properties, adds MyObject to an array list, serializes
that array list to binary and sends over http. The client
deserializes, looks in the array list, casts the object to MyObject
type and displays the properties in separate text boxes.

Where/why would the CLR manipulate the date property based on the
local time zone before displaying the value?

(Interstingly I found the threshold to be '3/26/2008 4:00:00 AM' to be
where the west coast app will actual display '3/26/2008' - '3/26/2008
3:59:59 AM' will still show '3/25/2008'. Could the '3' in the hours
place be related to the three hour difference between the east and
west coast?).

Thanks again for the help.

[Looch]

I found the answer - DateTime.AddHours

Thanks again.

[Steve Gerrard]

Looch wrote:

Thanks for the quick responses.

Where/why would the CLR manipulate the date property based on the
local time zone before displaying the value?

serializes
that array list to binary and sends over http.

the serialized date will include a time zone...

>The client
deserializes,

deserializing will adjust the date to local time.

[GArlington]

On Mar 26, 11:31 pm, Looch <[e-mail]:

Thanks for the quick responses.

I'm certainly not disagreeing but I don't get it. The remotable object
method in question selects four fields from the db (one being the
datetime type mentioned above)

<snip>

If you consider that this date/time can be create/edit date/time...
User 1 in New York creates/edits the record, User 2 in California
opens the same record few minutes later...
What do you expect User 2 to see? That the particular record WILL be
created/edited in 3 Hours and 55 minutes?

[Looch]

I guess I was expecting that if User1 (in New York) created a record
where one of the columns is a datetime type and the value created was
'3/26/2008 3:12:53 AM' that if User2 in California queried that record
and returned the value of that same column the return value would be
'3/26/2008 3:12:53 AM'. Instead I was getting the value minus four
hours.

[Stephany Young]

The issue is, I think you find when you delve deeper, is one of
serialization.

The remoting host (at the server end), will be serializing the datetime, and
the local remoting client will be deserializing it.

Unless it is told otherwise, the remoting host will including timezone
information in the serialized datetime. The timezone information will be is
respect of the timezone setting for the 'box' on which the serialization is
performed.

When the local remoting client deserializes it, because it contains timezone
information, that timezone information is honoured. The interpretation of
the value will be in respect of the timezone setting for the 'box' on which
the deserialization is performed, but taking into account the timezone
information embedded in the serialized value.

For example the value of:
3/26/2008 3:12:53 AM
will be serialized as something like:
2008-03-26T03:12:53Z+4:00

To get the behaviour you want, you would need to code the host and client
portions of the remotable application to ensure that all datetime values are
serialized and deserialized in a timezone agnostic manner.

Clear as mud????
"Looch" <lu**********@yahoo.comwrote in message
news:03**********************************@i7g2000p rf.googlegroups.com...

>I guess I was expecting that if User1 (in New York) created a record
where one of the columns is a datetime type and the value created was
'3/26/2008 3:12:53 AM' that if User2 in California queried that record
and returned the value of that same column the return value would be
'3/26/2008 3:12:53 AM'. Instead I was getting the value minus four
hours.