On 2 Aug 2005 00:28:41 -0700, "PromisedOyster" <PromisedOyster@hotmail.com> wrote:

>We have a client/server WinForms/C# application that uses .NET Remoting
>for the middleware. There is a SQL Server database at the back-end. (I
>believe that the same issue exists with WebServices).
>
>The server machine is in one time zone. Some users are in another time
>zone. They connect to the server using .NET Remoting and data is stored
>in a SQL Server database.
>
>If we pass Typed DataSets across the wire then DateTime columns within
>the Typed DataSet work well, presumably because of the Locale property
>on the DataSet. ie the date in the database is the local date/time and
>the date on the records that are returned to/from the client are in
>local time.
>
>However, there are couple of other instances where this model does not
>work:
>
>(1) Passing simple C# DateTime structs across the server boundary do
>not convert to the correct time zone. There is no conversion to the
>local time zone, so the data held may be a few hours out.
>
>(2) When we use DateTime columns to store Date only values. eg
>'12/2/2000 00:00:00' gets presented as '12/1/2000 21:00'
>
>What are the options to get around this problem?
>
>(1) can be solved by us passing datasets across the wire, but means
>additional load which we could possibly wear.
>
>I beleive that UTC is a way around (2). However, I am uncertain as to
>why '12/2/2000 00:00:00' in the dataset in the client time zone, then
>gets stored exactly the same in the database in the different server
>time zone (ie NO conversion) which is good BUT when retrieving, a
>conversion takes place causing no end of confusion.