Are TimeZoneInfo.Id indexes are always the same?

Question

I listed all the timezone IDs by using the TimeZoneInfo.Id .net property and I see that these IDs are language specific This means I can't find the one I am looking for by it's name on operating systems using different languages.

Its very tempting to simply pick the one I need based on its index in the list, but does a given index always points to the same timezone or is it varied by OS releases?

Answer 1

The Id values from TimeZoneInfo correspond to the registry keys under the following path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones

They are always in English, and are not localized by OS language. The values that are localized are in the DisplayName, StandardName and DaylightName properties, which are localized by the OS language (not the current .NET culture).

In general, you can rely on these being reasonably consistent across machines, as long as the machines are kept updated. If they are not kept updated, you risk having inconsistencies.

The time zones are updated on a regular basis via Windows Update, and the hotfixes described at microsoft.com/time. If a machine is not up to date, it is possible that it will not have a newly introduced time zone, or that it will not have the latest changes in daylight saving time rules for an existing time zone.

For example:

• KB3039024 introduced the "Eastern Standard Time (Mexico)" time zone, which covers the Mexican state of Quintana Roo, containing the cities of Chetumal and Cancun. This was introduced due to changes in Mexican law in 2015, which moved this area from UTC-06:00 to UTC-05:00.

  If one did not have this update, then they would not find this time zone on their computer, and thus it couldn't be found with TimeZoneInfo.FindSystemTimeZoneById.

• There was a follow up in KB3049874 which then removed daylight saving time from this new time zone, as the original Mexican announcement was unclear with this regard.

  If one had the first update, but not the second, then they would potentially get different results when using TimeZoneInfo to convert times with this zone.

If your situation requires that you can't rely on a particular machine being kept updated, then you could consider serializing the time zone information from one machine and deserializing it on the other. This can be done with the ToSerializedString and FromSerializedString methods on the TimeZoneInfo class.