[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search

CLDR Ticket #9900(closed data: moot)

Opened 19 months ago

Last modified 8 months ago

Some Microsoft Time Zone Ids are not handled

Reported by: guillaume.vauvert.pro@… Owned by: gregsla
Component: timezone Data Locale:
Phase: rc Review:
Weeks: Data Xpath:


In http://cldr.unicode.org/index/bug-reports#TOC-Dates-and-Times, Microsoft link https://www.microsoft.com/globaldev/nlsweb/ does not exists.
I found this link that list the Microsoft Time Zone IDs:

From this list, some Time Zone Ids are not handled by icu4j (I suppose that is due to cldr):
Dateline Standard Time
Mexico Standard Time 2
U.S. Mountain Standard Time
Mexico Standard Time
U.S. Eastern Standard Time
S.A. Pacific Standard Time
S.A. Western Standard Time
Pacific S.A. Standard Time
Newfoundland and Labrador Standard Time
S.A. Eastern Standard Time
Mid-Atlantic Standard Time
Transitional Islamic State of Afghanistan Standard Time
S.E. Asia Standard Time
A.U.S. Central Standard Time
A.U.S. Eastern Standard Time
Fiji Islands Standard Time

Do you plan to support them ?


Change History

comment:1 Changed 18 months ago by emmons

  • Owner changed from anybody to yoshito
  • Phase changed from dsub to rc
  • Priority changed from assess to medium
  • Status changed from new to accepted
  • Milestone changed from UNSCH to 31

comment:2 Changed 18 months ago by kristi

  • Cc gregsla@… added

comment:3 Changed 18 months ago by yoshito

Most of these are not Unique IDs used by Windows, or very old ones.

For example,

I guess "Mexico Standard Time 2" was used before, but no longer exist. The zone ID for "(UTC-07:00) Chihuahua, La Paz, Mazatlan" is "Mountain Standard Time (Mexico)" now.

I'm sure if "U.S. Mountain Standard Time" is ever used. I'm sure the zone ID is for US Mountain time is "US Mountain Standard Time" for years.

The link referenced here is for Windows Embedded and the pages says "© 2006 Microsoft Corporation. All rights reserved." So it's quite old document.

CLDR does not capture these historic/deprecated IDs.

comment:4 Changed 18 months ago by gregsla

It does indeed seem like this MSDN page is obsolete and should be removed: https://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx
Some of the ID names are just plain wrong and have never existed, e.g. “A.U.S. Central Standard Time” and other zones have periods that make no sense, it should be “AUS”. And there are other substitutions and weirdness in these names, for example, adding the former official name element “Transitional Islamic State” to Afghanistan, etc. This entire list seems like a big mistake. I am not even sure what the “Index” value is on the table.

This page seems to be more up to date: https://msdn.microsoft.com/en-us/library/gg154758.aspx . I don’t know if there is a standard place to get the full list of Windows time zones, maybe Matt knows.

The zones you called out all appear to be current valid Windows zones, just the names are wrong. Below is a mapping to the correct TZID. I am not sure about the Mexico cases.

0 Dateline Standard Time
510? Mexico Standard Time 2
520 U.S. Mountain Standard Time
630? Mexico Standard Time
700 U.S. Eastern Standard Time
710 S.A. Pacific Standard Time
830 S.A. Western Standard Time
820 Pacific S.A. Standard Time
900 Newfoundland and Labrador Standard Time
940 S.A. Eastern Standard Time
1000 Mid-Atlantic Standard Time
1630 Transitional Islamic State of Afghanistan Standard Time
1910 S.E. Asia Standard Time
2130 A.U.S. Central Standard Time
2200 A.U.S. Eastern Standard Time
2400 Fiji Islands Standard Time

I believe that it is true that our KeyNames are static and should never change, even if they are no longer referring to current places or are otherwise obsolete. The Friendly names can change. So I do find that old MSDN page especially strange, since it appears to have munged keynames, which should never happen.

I have reached out to someone here at MS who might have more background info.

comment:5 Changed 16 months ago by yoshito

  • Owner changed from yoshito to gregsla
  • Milestone changed from 31 to 32

I'll reassign this ticket to Greg.
I don't think we need to make any changes in CLDR.

comment:6 Changed 8 months ago by gregsla

  • Status changed from accepted to closed
  • Resolution set to moot

The MSDN article is outdated and no longer valid. The data in the WindowsZones.XML is complete and handles all valid Windows TZ ID strings.


Add a comment

Modify Ticket

as closed
Next status will be 'new'
Next status will be 'closed'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.