 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / March 2008Strange 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 > 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 [quoted text clipped - 5 lines] > 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... Why can't it be to do with timezones? I wouldn't be at all surprised if the data was being adjusted to/from local time somewhere. Timezones can frankly be a pain to get right :(  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk 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. I found the answer - DateTime.AddHours Thanks again. > 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. > 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? 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. 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???? >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. > All, > [quoted text clipped - 7 lines] > 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? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.