Last post Mar 08, 2009 09:38 PM by mbanavige
Mar 08, 2009 08:46 PM|erincarikan|LINK
We have a solution which is being used in different cities and time zones in USA. And our production servers reside in EST(GMT-5). The dates in our db is in EST time zone too. So if a user from chicago logs on to our system portal, they should see chicago
time, not the ny time. If somebody from NY logs on they should see NY time.
As a solution I was keeping a table of user market segments and hour offset with respect to GMT which is -5 for NY and -6 for CHI. and I was returning date field in gmt and I was customizing it in data layer according to users market segment and that's how
I returned correct datetime field for each user. Anyway here's the problem since USA had the time change earlier than other countries for 3 weeks NY will be GMT-4 and CHI will be GMT-5. I can reference everything to EST instead of GMT as a solution, but our
soldution will be implemented overseas soon, I need to find a worldwide solution for this problem.
If you can show me how to handle this problem, I'd be really glad.
Mar 08, 2009 08:52 PM|mbanavige|LINK
An offset from GMT is usually insufficient as it does not account for daylight savings time.
Instead, store all datetimes as UTC and then allow all your members to specify their specific timezoneinfo ID.
Then you can convert from utc to the user desired local time
Note: The TimeZoneInfo class is new to .NET 3.5
Mar 08, 2009 09:03 PM|erincarikan|LINK
Mar 08, 2009 09:11 PM|mbanavige|LINK
Prior to 3.5 there was no built-in way that i know of to handle daylight savings time issues.
what If I convert est datetime to utc in the stored procedure
Keep in mind that doing this compounds your issue. You need to know if your EST datetime is expressed in daylight saving time or not and then, after converting to utc, you'll still need to know if your target timezone is in daylight savings time or not.
different timezones move in and out of daylight savings time on different schedules.
I have seen 3rd party components indicate that they can handle it.
For some developers that need to deal with a global audience, the TimeZoneInfo class in 3.5 represents a "must have" upgrade.
Mar 08, 2009 09:23 PM|erincarikan|LINK
Mar 08, 2009 09:38 PM|mbanavige|LINK
Of course I can create a rule database for time changes for every country in the world
That is essentially what the 3rd party components endeavor to achieve and what you get with 3.5. Also keep in mind that the rules have changed over the years so even something like EST would require multiple entries in the rules database. Another issue
with storing your times as EST is that you cannot fully convert from EST to UTC. For at least 1 hour per year, there is a time that repeats. So if you do not know if the time was stored before or after the DST change, then you cannot accurately convert it
If you absolutely cannot convert to 3.5 then you may want to start looking to see if there's a reasonably priced 3rd party component available.