locked
Time Zone design weakness RRS feed

  • Question

  • Microsoft has chosen a very clumsy way to implement Time zone and Daylight Saving Time (DST) rules.

    The api used is TimeZoneInfo

    Usage example TimeZoneInfo.FindSystemTimeZoneById(timeZoneId)

    The time zone info is contained in the registry, which means that if you are running a website which is being hosted by a third party, your app may not have permission to read the registry.

    If you then create your own customized list of time zone ids, you then have to keep them updated which sort of defeats the purpose.

     A much better way would be to provide a web service for time zone info.

    Another weakness is that many countries have time zone identifiers that are for regions. But a country may decide to change its time zone region?

    This could happen for political reasons where a country straddles two time zone regions.

    It would then show up as a bug with incorrect times being displayed for that country.

    It couldn’t be pre-empted as the country in question has an ID for a region.

    It would be much better for each country to have its own time zone id, which could then be sub-divided into more than one time zone if that country was big enough to require more than one time zone.

    Thursday, November 1, 2012 10:06 AM

Answers

  • Regarding concern about reading registry, aren't the correct way is to call TimeZoneInfo.GetSystemTimeZones() and then use LINQ's .Where() to filter out the one you need? I think it's much more flexible that way because even for previously non-existant country, they could have selected their timezone by UTC offset instead of names.

    And no, providing webservice is NOT a good decision. For one thing webservice is sloooooow in response time, for the others, applications written in .NET framework often runs in restricted environment that do not have access to external network. That means such function will have to wait for timeout before return, and that means even a longer return time.

    Regarding associate timezone with country... you have know it by now, U.S. herself has 4 timezones so it's never consider a good idea.

    It would have been a good idea to revise NTP to allow WinTime service update the timezone information there, but we'd have to find someone figure out how to do that first (protocols using UDP have to tolarate packet loss).

    Given timezone does not change often (most I.T. staffs just create 1 image file, then use it to clone on other coperate machines, the others will just include that setting in unattended answer file so they also only needed to set that once), I think the current approach is quite acceptable and there's nothing much to complain on.





    • Edited by cheong00Editor Friday, November 2, 2012 3:19 AM
    • Marked as answer by Mike Feng Wednesday, November 7, 2012 2:01 PM
    Friday, November 2, 2012 3:12 AM
    Answerer
  • I don't think it is as bad as you portray it.  Most of the registry keys in a server can be read without issues, even the ones in HKLM.  Have you found a host where this is not true?  Even if you have, I bet they'll fix the problem if you escalate a support ticket to them.  The last thing they want is lose a customer over a simple thing like this one, I would say.

    Also countries change DST rules frequently enough already, and Microsoft then rolls out hotfixes to provide updated information.  Yes, there's the possibility of a PC being "out of sync" temporarily, but I don't see how a web service would be free of this problem.  Someone has to feed the correct data to the web service, right?  Sure, it may update faster than applying hotfixes to many servers, but then again, that service would be extra traffic some companies would prohibit.

    So all in all, I'm not sure if you are looking for some sort of answer to this, but what I can say is that I don't really think it is as bad.


    Jose R. MCP
    Code Samples

    • Marked as answer by Mike Feng Wednesday, November 7, 2012 2:01 PM
    Thursday, November 1, 2012 6:44 PM

All replies

  • I don't think it is as bad as you portray it.  Most of the registry keys in a server can be read without issues, even the ones in HKLM.  Have you found a host where this is not true?  Even if you have, I bet they'll fix the problem if you escalate a support ticket to them.  The last thing they want is lose a customer over a simple thing like this one, I would say.

    Also countries change DST rules frequently enough already, and Microsoft then rolls out hotfixes to provide updated information.  Yes, there's the possibility of a PC being "out of sync" temporarily, but I don't see how a web service would be free of this problem.  Someone has to feed the correct data to the web service, right?  Sure, it may update faster than applying hotfixes to many servers, but then again, that service would be extra traffic some companies would prohibit.

    So all in all, I'm not sure if you are looking for some sort of answer to this, but what I can say is that I don't really think it is as bad.


    Jose R. MCP
    Code Samples

    • Marked as answer by Mike Feng Wednesday, November 7, 2012 2:01 PM
    Thursday, November 1, 2012 6:44 PM
  • Regarding concern about reading registry, aren't the correct way is to call TimeZoneInfo.GetSystemTimeZones() and then use LINQ's .Where() to filter out the one you need? I think it's much more flexible that way because even for previously non-existant country, they could have selected their timezone by UTC offset instead of names.

    And no, providing webservice is NOT a good decision. For one thing webservice is sloooooow in response time, for the others, applications written in .NET framework often runs in restricted environment that do not have access to external network. That means such function will have to wait for timeout before return, and that means even a longer return time.

    Regarding associate timezone with country... you have know it by now, U.S. herself has 4 timezones so it's never consider a good idea.

    It would have been a good idea to revise NTP to allow WinTime service update the timezone information there, but we'd have to find someone figure out how to do that first (protocols using UDP have to tolarate packet loss).

    Given timezone does not change often (most I.T. staffs just create 1 image file, then use it to clone on other coperate machines, the others will just include that setting in unattended answer file so they also only needed to set that once), I think the current approach is quite acceptable and there's nothing much to complain on.





    • Edited by cheong00Editor Friday, November 2, 2012 3:19 AM
    • Marked as answer by Mike Feng Wednesday, November 7, 2012 2:01 PM
    Friday, November 2, 2012 3:12 AM
    Answerer