-
Notifications
You must be signed in to change notification settings - Fork 835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some packed links differ from IANA source files #835
Labels
Comments
This was referenced May 1, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While investigating a bug in a separate plugin, I found some oddities in the default packed data files provided by
moment-timezone
.Some zones in
moment-timezone
are listed as links in the IANA source files, and vice versa. This is due to the way the compilation process creates the packed files.zic
into binaryTZif
files — one per zone or link. At this point, the information about which identifiers areZone
s and which areLink
s is lost.zdump
, then compiled into a raw JSON file in thedata/unpacked
directory.packed
file, combining zones with identical data into a single source zone and multiple links. Because there's no information brought over from the IANA source files, the choice of which zone is the source and which are links can differ from IANA.For most use cases, this difference doesn't really matter, because
moment-timezone
transparently handles the links just the same as source zones. Where it gets odd is with the relatively newcountries
data. Now there are some countries that list somelinks
as their primary zones, while others just point straight at the source zone.I ran a quick script to identify these outliers:
Edit: There are actually more than that listed in
latest.json
vs2019c.json
— see #836For reference, this is the script...
Investigating further, I ran a script to identify all the links and zones in
moment-timezone
data that differ from the IANA source files:The script I ran...
The results...
It looks like this happens because the compression of multiple zones into links within
filterLinkPack
works on a first-in basis. The first zone processed in a list of identical zones is made the source, with the rest being links to it. Thezdump
data files are processed in alphabetical order, which explains whyAsia/Rangoon
is a link toAsia/Yangon
in the IANA files, but it's the other way around inmoment-timezone
(Asia/Rangoon
gets processed first in alphabetical order).The tests I ran were on
moment-timezone
0.5.28 and IANA data files for 2019c, but as far as I can tell this dates back to the first set of data files inmoment-timezone
(2014a). I see thegroup-leaders.json
file was added to help keep links consistent, but I think it just encoded the link directions from the already-incorrect data. (SeeAmerica/Fort_Wayne
, for example.)Realistically this is a fairly minor problem due to the transparent handling of links. But sometimes the data files are processed by other scripts to be passed in to
filterLinkPack
for custom builds, and I think having consistency with the source data is important.Edit September 2022: After some changes in recent IANA releases, there are now countries defined in the IANA sources with a primary zone that's a link to a different zone. The assumption of at least one
Zone
definition per country no longer holds true, so I don't think having links inmoment-timezone
's country data is a problem any more. The mismatch betweenZone
andLink
status still exists, though.The text was updated successfully, but these errors were encountered: