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
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
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.
Copyright (c) Marimer LLC