DateTime time zone conversions not required !

[GiriT]

Would appreciate some insight into how people are dealing with the
implicit conversion of timezones that .NET does.

If a server in one timezone delivers up a typed dataset to a component
in another (winform for example) then the timezone conversion takes
place. This is a pain if you are doing date based calculations on the
client using input in one timezone and data from another. (Take one
hour off a CET time and you go a day back in terms of days...)

What are people doing to conteract this? What are some sample
strategies? Any sample code to simply STOP this would help, but I
suspect there are more far reaching implications...

Thanks

[Nicholas Paldino [.NET/C# MVP]]

GiriT,

.NET shouldn't be doing anything to the dates to change them when you
are returning (and I have heard of no such feature). Is it possible that
this is happening on the database level, or some other level which you are
not aware of?

To get around things like this, I make sure that all dates stored in the
database are in UTC, and I do modification on them locally if need be.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- nick(dot)paldino=at=exisconsulting<dot>com

"GiriT" <gt******@prologis.com> wrote in message
news:f1**************************@posting.google.c om...

Would appreciate some insight into how people are dealing with the
implicit conversion of timezones that .NET does.

If a server in one timezone delivers up a typed dataset to a component
in another (winform for example) then the timezone conversion takes
place. This is a pain if you are doing date based calculations on the
client using input in one timezone and data from another. (Take one
hour off a CET time and you go a day back in terms of days...)

What are people doing to conteract this? What are some sample
strategies? Any sample code to simply STOP this would help, but I
suspect there are more far reaching implications...

Thanks

[Jeffrey Tan[MSFT]]

Hi ,

The TimeZone converstion at lease take place when you serialize the
DateTime object.
You can just follow Nicholas' suggestion, convert the DateTime object into
UTC.
I think you also can convert your DateTime object into a string and after
received construct a new DateTime object.

Hope this helps,

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: gt******@prologis.com (GiriT)
| Newsgroups: microsoft.public.dotnet.languages.csharp
| Subject: DateTime time zone conversions not required !
| Date: 10 Oct 2003 05:25:45 -0700
| Organization: http://groups.google.com
| Lines: 14
| Message-ID: <f1**************************@posting.google.com >
| NNTP-Posting-Host: 193.67.177.98
| Content-Type: text/plain; charset=ISO-8859-1
| Content-Transfer-Encoding: 8bit
| X-Trace: posting.google.com 1065788745 12856 127.0.0.1 (10 Oct 2003
12:25:45 GMT)
| X-Complaints-To: gr**********@google.com
| NNTP-Posting-Date: Fri, 10 Oct 2003 12:25:45 +0000 (UTC)
| Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed 00.sul.t-online.de!t-onlin
e.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnew s1.google.com!no
t-for-mail
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:190527
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| Would appreciate some insight into how people are dealing with the
| implicit conversion of timezones that .NET does.
|
| If a server in one timezone delivers up a typed dataset to a component
| in another (winform for example) then the timezone conversion takes
| place. This is a pain if you are doing date based calculations on the
| client using input in one timezone and data from another. (Take one
| hour off a CET time and you go a day back in terms of days...)
|
| What are people doing to conteract this? What are some sample
| strategies? Any sample code to simply STOP this would help, but I
| suspect there are more far reaching implications...
|
| Thanks
|

[Giri]

What is interesting is the following:

The database has a date as 10 Oct 1999 00:00 (ie midnight)

A webservice in CET (GMT+1) plucks this out of the database into a typed
dataset.

If you go direct to the webservice from a browser and use the VS.NET harness
you see the right date.

A component in a different timezone GMT receives this typed dataset. When
you then access the typed dataset's date field it has become.... 11 Oct
1999 22:00. Now this is strictly speaking correct as that is the time GMT
if you take daylight saving into account...

My problem is that all my dates are in as midnight... I don't care about
the "time" as such so converting to and from UTC is not realistic as the
dates when entered by the user into the system are specified as just dates
not daae and time in their timezone....

Luckily for me .Subtract returns a TimeSpan object, whose Days property is
returning the correct result (can you confirm this ?).

This doesn't resolve whether I should be :

a) Letting dates go in as midnight but then use .ToLocalTime() in the
timezone.
b) Engage in the complexity of dealing with time and convert to UTC on the
way in and ToLocal on the way out..
b) Any other strategy...

Be grateful for any advice on this.

[Jeffrey Tan[MSFT]]

Hi Giri,

I think a sample and easy to implement way of avoiding the timezone
conversion is convert the Datetime object to string, then in client side,
you can again convert the string into DateTime object.
If you want to do the timezone conversion, I think you should store the UTC
in server side and use tolocal method in client side.

Hope this helps,
Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: "Giri" <gt******@prologis.com>
| References: <f1**************************@posting.google.com >
<Xk**************@cpmsftngxa06.phx.gbl>
| Subject: Re: DateTime time zone conversions not required !
| Date: Tue, 21 Oct 2003 09:21:52 +0100
| Lines: 34
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <ua*************@TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: 193.67.177.98
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP10.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:192793
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| What is interesting is the following:
|
| The database has a date as 10 Oct 1999 00:00 (ie midnight)
|
| A webservice in CET (GMT+1) plucks this out of the database into a typed
| dataset.
|
| If you go direct to the webservice from a browser and use the VS.NET
harness
| you see the right date.
|
| A component in a different timezone GMT receives this typed dataset. When
| you then access the typed dataset's date field it has become.... 11 Oct
| 1999 22:00. Now this is strictly speaking correct as that is the time GMT
| if you take daylight saving into account...
|
| My problem is that all my dates are in as midnight... I don't care about
| the "time" as such so converting to and from UTC is not realistic as the
| dates when entered by the user into the system are specified as just dates
| not daae and time in their timezone....
|
| Luckily for me .Subtract returns a TimeSpan object, whose Days property is
| returning the correct result (can you confirm this ?).
|
| This doesn't resolve whether I should be :
|
| a) Letting dates go in as midnight but then use .ToLocalTime() in the
| timezone.
| b) Engage in the complexity of dealing with time and convert to UTC on the
| way in and ToLocal on the way out..
| b) Any other strategy...
|
| Be grateful for any advice on this.
|
|
|