471,310 Members | 1,090 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,310 software developers and data experts.

Strange DateTime Problem

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
Mar 26 '08 #1
7 1712

"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?
Mar 26 '08 #2
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.
Mar 26 '08 #3
I found the answer - DateTime.AddHours

Thanks again.

Mar 26 '08 #4
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.
Mar 27 '08 #5
On Mar 26, 11:31 pm, Looch <lucianoj2...@yahoo.comwrote:
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?
Mar 27 '08 #6
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.
Mar 27 '08 #7
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.
Mar 27 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Davewadd | last post: by
3 posts views Thread by Jim in Arizona | last post: by
reply views Thread by David Pratt | last post: by
14 posts views Thread by dananrg | last post: by
1 post views Thread by Tino Lange | last post: by
3 posts views Thread by Jeremy Chapman | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.