History/explanation for "time zones" on Windows

Question

Not sure if superuser.com is the proper StackExchange site to ask this question; if not, refer me to the most appropriate of the sites.

What is the origin of the time zones that come with Windows? For the sake of example, I shall list some here (from using PowerShell, but the info is not .NET-specific):

PS C:\Users> [TimeZoneInfo]::FindSystemTimeZoneById("W. Europe Standard Time")
Id                         : W. Europe Standard Time
HasIanaId                  : False
DisplayName                : (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
StandardName               : W. Europe Standard Time
DaylightName               : W. Europe Daylight Time
BaseUtcOffset              : 01:00:00
SupportsDaylightSavingTime : True
PS C:\Users> [TimeZoneInfo]::FindSystemTimeZoneById("Central Europe Standard Time")
Id                         : Central Europe Standard Time
HasIanaId                  : False
DisplayName                : (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague
StandardName               : Central Europe Standard Time
DaylightName               : Central Europe Daylight Time
BaseUtcOffset              : 01:00:00
SupportsDaylightSavingTime : True
PS C:\Users> [TimeZoneInfo]::FindSystemTimeZoneById("Romance Standard Time")
Id                         : Romance Standard Time
HasIanaId                  : False
DisplayName                : (UTC+01:00) Brussels, Copenhagen, Madrid, Paris
StandardName               : Romance Standard Time
DaylightName               : Romance Daylight Time
BaseUtcOffset              : 01:00:00
SupportsDaylightSavingTime : True
PS C:\Users> [TimeZoneInfo]::FindSystemTimeZoneById("Central European Standard Time")
Id                         : Central European Standard Time
HasIanaId                  : False
DisplayName                : (UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb
StandardName               : Central European Standard Time
DaylightName               : Central European Daylight Time
BaseUtcOffset              : 01:00:00
SupportsDaylightSavingTime : True

All these four entries ("W. Europe Standard Time", "Central Europe Standard Time", "Romance Standard Time", "Central European Standard Time") are essentially equivalent, but confusing in several ways. Here are some examples:

• The name W. Europe Standard Time is often used for UTC±00:00 used in Lisbon, London etc., so where does the name come from?
• The word Romance in the third one is curious. One city mentioned (Copenhagen) uses a non-Romance language (Danish, a Germanic language), while a city with clearly Romance association (Rome, from the name of which Romance is derived) is in another entry.
• There is no meaning to the groups. Like why are Amsterdam and Brussels in different groups? And why does Stockholm go together with Amsterdam while Copenhagen goes with Brussels?
• If you are in Oslo (not mentioned), would you pick Copenhagen or Stockholm?
• The names Central Europe Standard Time and Central European Standard Time are very similar? Why is Zagreb not grouped together with Ljubljana; the cities of the Balkans are completely randomly distributed between the two groups?

So my main question is, what is the explanation for these groups? Is there a map from tz database entries to the groups used by Windows?

Answer 1

All these four entries ("W. Europe Standard Time", "Central Europe Standard Time", "Romance Standard Time", "Central European Standard Time") are essentially equivalent, but confusing in several ways.

Yes.

The name W. Europe Standard Time is often used for UTC±00:00 used in Lisbon, London etc.

Colloquially, yes - "Western European Time" is applied to several places that are UTC+0. However, Windows thinks that's UTC+1. The Windows time zone ID for London and Lisbon is "GMT Standard Time".

so where does the name come from?

It's a mistake, that has been grandfathered in to the data.

The word Romance in the third one is curious. One city mentioned (Copenhagen) uses a non-Romance language (Danish, a Germanic language), while a city with clearly Romance association (Rome, from the name of which Romance is derived) is in another entry.

I think this is a stretch. It's more likely the individual who first proposed this zone entry thought that Paris was a romantic place. (Yes, I am being serious.)

There is no meaning to the groups. Like why are Amsterdam and Brussels in different groups? And why does Stockholm go together with Amsterdam while Copenhagen goes with Brussels?

No reason other than there were a long list of European countries and corresponding cities with the same time zone at the time the identifiers were chosen. I speculate they were broken into four to keep the drop-down list visible in the UI without making it super wide, or upsetting anyone by dropping one of them.

If you are in Oslo (not mentioned), would you pick Copenhagen or Stockholm?

I can't speak for what one would do, but the correct mapping would be Stockholm. (W. Europe Standard Time)

The names Central Europe Standard Time and Central European Standard Time are very similar? Why is Zagreb not grouped together with Ljubljana; the cities of the Balkans are completely randomly distributed between the two groups?

Yes.

So my main question is, what is the explanation for these groups?

I've researched this considerably, and the only reasonable answer I can offer is: Human behavior can often be seen as haphazard when reviewed over time. Hence the expression, "Hindsight is 20/20".

• Consider that the first APIs that used this data were part of the earliest versions of Windows NT. While the tz database project existed at the time, it wasn't as ubiquitous as it is today. Microsoft also did not have a culture of adopting open source technologies, or much interest on interoperability between systems with things as esoteric as time zones.

• It took much longer for there to be even a slight regard for historical time zone changes (Windows Vista added "Dynamic DST" to the registry entries).

• Generally speaking, the only motivation was having the clock on the taskbar be correct, for the time zones that Microsoft was selling Windows in. Thus, the list did not have to cover 100% of the world - but just the areas where there was a support contract. If you were using Windows in some other time zone, you probably didn't have a channel to convince someone at Microsoft that it was an important issue worth spending engineering money on.

• Microsoft also had had major problems with time zones interfering with product sales due to how they were labeled on maps. (See this blog or this older tz list post for more details.)

• Over time, more and more time zones were added to the list. Sometimes the changes were at request of customers, and sometimes they were in response to government change of standard offset or DST rules. Sometimes the changes were part of larger projects, or sometimes as one-offs. Often by different teams following what they thought was the right thing to do, but didn't necessarily align with precedent (ex: the "Russia Time Zone X" numbered zones).

The good news is, the world changed, and Microsoft has come a long way with it. Technologies like .NET have embraced IANA time zones where possible. So has Windows itself, in several areas such as WinRT/UWP. In 2016, I worked at Microsoft and helped the Windows team fill in the gaps. Now, as much as possible, there is a reasonably valid choice of time zone for any person on the planet (to align with Microsoft's revised mission statement: "to empower every person and every organization on the planet to achieve more"). There's a lovely piece in Wired magazine about these folks. I no longer work there, but the policies I helped put in place continue to support efforts to stay updated as time moves on. You can follow along with their work on the Microsoft DST/TZ blog.

Is there a map from tz database entries to the groups used by Windows?

Yes. The de-facto standard mapping is the windowsZones.xml file, found within the Unicode CLDR project. It is used by Windows itself, as well as .NET, many third-party libraries, and just about anything that runs ICU.

In .NET 6+, running on either non-Windows systems, or on modern Windows systems that include ICU, you can just use the IANA identifiers and leave the legacy conversion out of your programs. There is also my TimeZoneConverter library, which can do much of the same thing regardless of .NET version or OS.

Answer 2

Explanations may be found in the Microsoft article Introducing New Windows Time Zones from 2019:

1. Criteria for Creating New Time Zones in Windows

A new Windows time zone entry will be created when a country/region (including dependencies), or a first-order administrative division of a country/region (state, province, department, etc.), has a separate and distinct history of UTC offsets and DST rules from existing time zone entries. Additionally, a smaller geographic area (county, city, etc.) qualifies for a new Windows time zone entry when its current UTC offset and DST rule combination is not provided by another Windows time zone entry.

2. New Time Zones

The following time zones have been added, either because they are currently unrepresented, or because they have a unique history of changes in recent years.

The answer is then historical in nature - when countries change their rules, Microsoft may create new groups that include them, or move them to another group. Rules may include summer-time dates or anything that could have changed the times that Windows needed to set for that country.

Microsoft doesn't seem to be unifying groups when the rules change, preferring to keep previous groups, even if the entries in multiple groups use today the same time-zone.

Answer 3

I believe Romance is a reference to a linguistic group that is applied to a typical geographical region/jurisdiction. (Like "Suisse Romande" that is the term applied to designate the group of French-speaking cantons in Switzerland.) Romance language is a language directly derived from Latin, see https://en.wikipedia.org/wiki/Romance_languages. Oddly enough, the details of the given time zones do not match, or match partially. I suppose it started with particular jurisdictions when that tag made sense, and then it drifted from the original composition as DST rules changed - e.g. Denmark / Danish would hardly quality as a Latin-language speaking country.

Answer 4

There was an article in the Microsoft knowledge-base about this that I have read about 10 years ago.
I did some digging but I was not able to find that article again.

From what I remember:

Amsterdam and Brussels may be effectively the same time-zone now, but they were NOT in the past.
In order to make date-time calculations, that go back in time to those days, work correctly it is required to maintain these separate time-zones even though, today, they are functionality equivalent.

(I presume the same thing applies to the other time-zones.)

As for the odd names and weird zones: These are also historic and are kept around for compatibility reasons.