Timezone DayLightSaving

L

liming

Perch
Hey ASP.NET Gurus,

How do you guys handle timezone and daylightsavings in ASP.NET or should I say...what is the correct way to handle them together?

Currently, we managed to get everything setup straight to handle timezone differences, so basically if you assign a task in Beijing China with a Due date 1/31/2008 12:00:00am, users in U.S eastern shore will see a Due date 1/30/2008 11:00am instead. (13 hours of difference automatically adjusted depends on which user logs in to see it)

However, things get a little complicated with DayLightSavings comings in. For example, assuming a server admin wants to schedule a server shutdown at 2:30am during the "Spring forwards" (adds an hour in the spring) and the switch occurs at 2:00am. We have a problem already!! why?

The clock goes 1:58am, 1:59am, 3:01am. There is no such thing as 2:30am.

*Edit*
Just to make sure you understand why I feel it's important. Suppose it's the "Falls Back" time (removes the hour) and server admin simply said we will schedule a shutdown 1:30am. So we have

1:30am...... 1:58am, 1:59am, 1:00am...1:30am. (1:30 am occurs twice)

The user mis-interpreted the message, thinking server admin meant 1:30am after "fallsBack", so he's doing he's stuff online and all, but server admin meant 1:30am before "falls back", so you see? when the server admin shuts down the server, the user suddenly lost his data while doing the app. This could cause big problems.


I looked at the implementations out there already, articles, but no one seems to have a set of standard rules to handles these in .NET 2.0. (I see .NET 1.1 stuffs, but lots of them are either addressed in 2.0 or changed a bit)

Any suggestion is appreciated it.
 
It's fairly simple: use UTC everywhere in your business logic.
Only when you get to the part of showing a date, or interpreting an entered date you have to worry about timezones and DST.

Key methods here are ToUniversalTime() and ToLocalTime() in the DateTime structure.
 
Subspace, that's correct. We have textboxs where we ask users to enter in due dates, such we need to parse them and convert to datetime.

We already took care of the UTC time and timezone differences, both in C# and Store procedures. We're just struggling with this whole Daytime saving crap.

Thanks anyway
 
I think I originally misunderstood the problem. You're talking about a user interface issue when someone schedules something during the DST shift in local time.

At first I thought you were talking about your application messing up if someone shut down the server it was running on during the DST shift :rolleyes:

Basically the local time entered or displayed is ambiguous unless you actually add the effective timezone. However, that would probably just confuse people for the other 8758 hours each year.

I think your best option is using IsAmbiguousTime(DateTime) in the TimeZoneInfo class (http://msdn2.microsoft.com/en-us/library/system.timezoneinfo.isambiguoustime.aspx).
That way you can detect if an entered time is ambiguous due to the clock being turned back an hour and tell them to sod off and schedule at some other time or something ;) Something might be allowing them to enter the time in UTC instead, I don't know of a 'standard' way to handle this. Alternatively you can do something with GetAmbiguousTimeOffsets(DateTime) to allow them to pick the right time from a list.

As for the non-existant time.. have you tested what happens when you even try to convert it to a UTC DateTime? I personally never checked, and I'm already running horribly late for work :p
 
Subspace,

That's exactly what I need, EXCEPT it's a .NET 3.5 feature :( I'm slow, still on .NET 2.0. lol.

Okay, time for me to write my own IsAmbiguous method.
 
Bummer :(
IsInvalidTime() is the one that could have been used to fix the shift to summer time.

Writing your own is kind of annoying. At least I couldn't find a way to get the date and time where the daylight shift occurs? Perhaps I'm just overlooking. The alternatives are providing that information yourself (eww) or adding and subtracting an hour from the time you're checking and seeing wether timeMinusOneHour.IsDaylightSavingTime() differs from timePlusOneHour.IsDaylightSavingTime(). Or something along that line... more ewww :)
 
You must log in or register to reply here.
Back
Top