<chrono>: Should divergence between ICU and IANA be reported?

[StephanTLavavej]

While implementing C++20 <chrono> time zones, @d-winsor discovered divergence between what ICU.dll implements and what the IANA database contains:

STL/tests/std/tests/P0355R7_calendars_and_time_zones_time_zones/test.cpp

Lines 151 to 157 in 027fc9f

	// these are some example in which the ICU.dll and IANA database diverge in what they consider a zone or a link
	assert(_Locate_zone_impl(my_tzdb.links, "Atlantic/Faroe") != nullptr); // is a time_zone in IANA
	assert(_Locate_zone_impl(my_tzdb.zones, "Africa/Addis_Ababa") != nullptr); // is a time_zone_link in IANA
	assert(_Locate_zone_impl(my_tzdb.links, "PST") != nullptr); // time_zone_link does not exist in IANA
	assert(_Locate_zone_impl(my_tzdb.links, "Africa/Asmara") != nullptr); // matches IANA but target is wrong
	assert(_Locate_zone_impl(my_tzdb.links, "Africa/Asmara")->target() == "Africa/Asmera"); // target == Africa/Nairobi
	assert(_Locate_zone_impl(my_tzdb.zones, "America/Nuuk") == nullptr); // does not exist in ICU (very rare)

Are these issues that should be reported to ICU upstream?

[ZaldronGG]

Perhaps @mattjohnsonpint could recommend a course of action given his extensive expertise in this field?

[mattjohnsonpint]

This is expected. IANA has a different definition of what is canonical than ICU/CLDR.

• IANA: The Zone entry is the one that is currently primary and canonical. When either two zones merge or when the name of a zone changes, a Link entry for the old zone name is created to point at the new zone name.

• ICU/CLDR: Localization requires a stable identifier. Each group of zones and links is added to the bcp47/timezone.xml, with the zone entry coming first in the list. It is the stable canonical name and will never change.

Also, ICU has its own set of backwards-compatibility links and zones that are not in IANA or CLDR.
https://github.com/unicode-org/icu/blob/main/icu4c/source/tools/tzcode/icuzones

Lastly, there are four zones with older abbreviation-style names in IANA that that are not recognized by CLDR
https://github.com/eggert/tz/blob/3f949ece2dbaaebd970396bd132424e131f4f96a/europe#L739-L745

In short - there shouldn't be an expectation of strict consistency here. Most of these issues are known, and in they matter only in edge cases, not the general case.

[mattjohnsonpint]

Just to go item by item:

• Atlantic/Faroe
  • IANA Zone. Was originally spelled Atlantic/Faeroe.
  • CLDR has <type name="fotho" description="Faroe Islands" alias="Atlantic/Faeroe Atlantic/Faroe"/> (old spelling first)
• Africa/Addis_Ababa
  • IANA Link to Africa/Nairobi
  • CLDR has <type name="etadd" description="Addis Ababa, Ethiopia" alias="Africa/Addis_Ababa"/> (can't remove a stable id)
• PST
  • Link in ICU's special file
  • Not in IANA or CLDR
• Africa/Asmara
  • IANA used to link this to Africa/Asmera spelling but now links it to Africa/Nairobi (links to links are not allowed in IANA)
  • CLDR can't remove or update stable ids, so it has <type name="erasm" description="Asmara, Eritrea" alias="Africa/Asmera Africa/Asmara"/>
• America/Nuuk
  • IANA zone. Used to be America/Godthab, which is now a link.
  • CLDR has <type name="glgoh" description="Nuuk (Godthåb), Greenland" alias="America/Godthab America/Nuuk"/>
  • The comment "does not exist in ICU" is incorrect. It was added with CLDR-13739 in CLDR 38 (ICU 68), corresponding with IANA 2020a. (If it's not there, this may be related to a Windows ICU data servicing issue.)

[StephanTLavavej]

Great, thank you! I'll update the comment accordingly. I suspect it takes some time for new versions of ICU to ship in Windows.