DateTime Serialization - Across Timezones

DateTime Serialization - Across Timezones

Old forum URL: forums.lhotka.net/forums/t/7288.aspx


DCottle posted on Thursday, July 16, 2009

One of our business users just sent the following scenario to us.  They are using DataSets via WCF, and are seeing this problem.  We are using CSLA via WCF and they want to make sure we will not have the same problem.  Can anyone address whether or not CSLA will have this same bug?

------------------------------------------------------------------------

User1 is in the mountain time zone and we are in the central time zone.  When User1 adds a record that is expecting a date only, the data getting saved in the database gets posted with that date plus 1 hour – the time zone difference between her and us.  This has become a bigger issue since she is in testing deals now and deals are NOT making it on to the board because of this issue.  There are about 15 traders in a different time zone than us.  This will certainly spill on to areas being developed in CSLA as well…

 

PROBLEM

The problem is NOT the custom controls – they are operating the same as the M$ datetime picker control – sorry to spoil some peoples fun.  The issue is the serialization (client side packaging of the WCF methods) and deserialization (server side unpackaging of the WCF methods) of the datasets.  When a dataset with a date gets serialized, the time portion of the attribute includes the local time with the time offset according to UTC values (i.e. <TestDate>2009-07-13T00:00:00-05:00</TestDate>).  When you deserialize, the time portion takes that local time and applies the offset plus the UTC offset for the receiving machine.

 

Thus, we end up with the hours being different if in different timezones.

 

-----------------------------------------------------

 

Thanks,

 

David

tmg4340 replied on Thursday, July 16, 2009

If you continue to transmit your dates as you are, then CSLA will have the same issues that your DataSets do, because the behavior is specific to how dates are handled in .NET, not the technology that contains them.

The generally-recommended procedure in this case is to deal with dates as UTC and translate on either end to/from the local timezone.  That's pretty much the only way to reliably deal with this, and there are still some gotchas surrounding daylight savings time.  Those are usually minimized in most scenarios, since users aren't entering/viewing data in the wee hours of the night.  But it could be an issue for automated processes.  The new TimeZone class in .NET 3.5 is also the preferred option over the DateTime methods, because it's better tuned to timezone offsets and daylight savings times, and gives more options to deal with these date issues.  But that's only available in 3.5.

HTH

- Scott

ajj3085 replied on Monday, July 20, 2009

Yes, probably best to do this translation when the data its being moved to or from the business layer into the data layer.

I had tweaked my Linq 2 Sql classes to do just this. There's a property, which is readonly which returns the datetime in UTC. Another property has a getter that will translate to the current timezone (this is setup by Csla as part of the context, so it works nicely) and the setter assumes its getting a local time and converts to UTC.

This works pretty well for me. Although I don't deal with users crossing timezones, I did setup something with NotificationServices... and it seems easier to always store UTC times so that NS works properly.

bt1 replied on Monday, July 20, 2009

I have worked on translation of UTC to Local and back before.  You can take a look at the following post to see if this help you.

http://forums.lhotka.net/forums/thread/25721.aspx

Copyright (c) Marimer LLC