Inconsistent Zone Identifiers in Noda

Question

When I check this property...

var t = DateTimeZoneProviders.Tzdb.Ids;

...it contains values such as:

• US/Alaska
• US/Eastern
• US/Hawaii
• US/Pacific
• US/Arizona
• America/Denver
• America/Chicago
• America/Phoenix
• America/Los_Angelos

But when I access MapZones, all the "US" entries disappear:

var mappings = TzdbDateTimeZoneSource.Default.WindowsMapping.MapZones;

var stuff = mappings.SelectMany(w => w.TzdbIds)
      .Where(v => v.StartsWith("America") || v.StartsWith("US"));

In the above example, it does return "America" entries - such as "America/Phoenix" - but all the "US" entries are gone.

Why?

The "US" values, such as "US/Eastern" or "US/Pacific" are among the most important to have in the map - and yet they are not there. I don't understand.

Answer 1

A few things:

• Zones like US/* are primarily in the TZDB for backwards compatibility purposes. They are "links" to the canonical zones, rather than zones unto themselves. The are valid identifiers, but you should usually avoid using them for new development.

  The list on Wikipedia shows all of the zones and links, and indicates which links point at which canonical zones. For example, "US/Pacific" is a link to "America/Los_Angeles".

  In the tzdb sources, links are identified with the Link keyword. You will find the US/* zones in the backward file. You will also find other links scattered around the other files, usually near the associated zone definition.

• The WindowsMapping class in Noda Time exposes the Unicode CLDR windows zone mapping data. CLDR has a different idea of what is canonical than the TZDB does. Zones like US/Eastern are not canonical by either standard, but take India for example. The TZDB uses the newest Asia/Kolkata as the canonical zone, while Asia/Calcutta is a link. But since Asia/Calcutta was the original value, CLDR considers that canonical instead. Therefore, you won't find Asia/Kolkata in the WindowsMapping data in Noda Time. You have to first resolve the zone to the one TZDB uses.

• I've already completed functions for Noda Time that take all of these considerations into account. You can find them here.