Csla 3.8 DateTime Issue with Data Portal

m-s posted on Tuesday, October 13, 2009

We are running csla version 3.8 and are experiencing some issues with DateTime getting changed once the object gets to the dataportal. A date time is set at the creation of the object on the client side (the client is eastern time) and then once the object gets to the server side it is changed to central time. Is there some conversion that csla is doing behind the scenes on a date time on its trips to the data portal and back? Has anyone experienced this before?

RockfordLhotka replied on Tuesday, October 13, 2009

I assume this behavior isn't new in 3.8? The data portal hasn't changed from 3.7 (or earlier).

With that assumption, the problem of date values crossing timezone boundaries is a widely known issue within .NET, and if you search the web you can find some good information on the issue and possible solutions.

One thing to consider, is that Microsoft recently (in .NET 3.5?) added a whole new datetime type to deal with timezones - or at least to help deal with them.

m-s replied on Tuesday, October 13, 2009

It could be a .Net issue. The reason I suspected something with the data portal, is because I'm running 3 tier on my dev machine (physically central time) with my time zone set to eastern and the hops across the local data portal are causing a change. Will the woes of computers and dates/times ever end?

RockfordLhotka replied on Tuesday, October 13, 2009

Ultimately the data portal uses the BinaryFormatter or NDCS to serialize your data values. So your DateTime value is serialized into some format for transport over the wire. I don't know what format they serialize into - it could be a numeric or string representation, and is probably different depending on the serializer that's used.

That serialized representation is then deserialized back into a DateTime value on the server.

If the client and server have different timezones, the value can be deserialized into a "different value" because the serialization and deserialization aren't symmetric due to the context.

As I say, there are numerous blog posts and other information out there that discuss this issue in substantial detail. And the specifics are different with different serializers, etc - which means the solutions may also vary.