I'd like to use the built in TimeZoneInfo object, but I understand that
relies on the server's registry settings. We currently have 18 load balanced web servers that host our WCF service layer, and I believe our TechOps team is vigilant in making sure that all servers are patched with the same service pack at all times.
I also need to pay special attention to the various US Time Zones, specifically Pacific, Mountain, Central and Eastern. Can I assume that the string based Id field will not change anytime soon? For example, if I call
TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time")
I want the appropriate TimeZoneInfo object to be returned.
So a few questions:
- What is the best way to deal with time zones, especially when it comes to the changing rules (US time zone rules changed in 2006) and determining offsets. Should I be trying something else? Keep in mind that the product team doesn't want the user to have to select their time zone and they are fine with time zones being inaccurately reported under certain conditions (e.g. if the user is in Mexico, it is ok to be reported as "Pacific Standard Time" instead of the more accurate "Pacific Standard Time (Mexico)".
- If I assume that all of our load balanced web servers are always running the same OS version and patch level, can I assume that I will get consistent results?
- Are there any other things I need to consider?