Potential Inconsistency in tz Database (2024b) for Mexico 1931
Dear IANA Team, I hope this message finds you well. My name is Bogdan Hoancea, and I am a software engineer at ABB. We maintain the software package tzdata<https://www.npmjs.com/package/tzdata>, which utilizes the tz database for generating time zone information. I am reaching out regarding a potential inconsistency I noticed in the latest tz database release (tzdata2024b/northamerica). Specifically, for Mexico in 1931, "May 1 23:00" appears to have been changed to "April 30 0:00," whereas it seems the correct adjustment should have been "Apr 30 0:00," in line with the rest of the table. [cid:image001.png@01DB0854.42FCA410] While it is always a possibility to handle this particular case in our software, I wanted to bring it to your attention in case it impacts other users as well, and also, we would prefer it if the root cause of the issue was handled. Thank you for your continued work in maintaining such a critical resource, and please feel free to reach out if any further information is required. Best regards, Bogdan Hoancea [https://signatures.spiritit.com/ABB_Logo_HR.png]<http://www.abb.com/> - Bogdan Hoancea Software engineer - SpiritIT Measurement & Analytics ABB b.v. Achtseweg Zuid 151A / Strijp-TQ Entrance 5 5651GW Eindhoven, The Netherlands Phone: +31 88 440 47 12 abb.com
Thanks for reporting that. The issue with "April" vs "Apr" is known. The documented data format allows any abbreviation of words that is unambiguous in context (where case is ignored), so that "April", "APRI", "apr", and "Ap" are all valid. However, some downstream parsers don't support any word other than "Apr" and so I installed a change to the development repository, here: https://github.com/eggert/tz/commit/926b507fa5c3192b1b68fab5910cbd3ba9377c97 Feel free to use that change in your own copies of the data. This change should appear in the next TZDB release. The next release isn't urgent, since 2024b was mostly for compatibility checking, and you can stick with 2024a if you'd prefer that. Also, please fix the NPM tzdata package so that it supports full names as well as abbreviations, to help avoid similar compatibility issues in the future. For example, NPM tzdata should be able to parse the tzdata.zi file that is shipped as part of the 2024b release <https://data.iana.org/time-zones/releases/tzdb-2024b.tar.lz>. This file uses abbreviations like "F" for February, "F" for Friday (allowed since it's in a different context), and "R" for Rule. Thanks.
účastníci (2)
-
Bogdan Hoancea -
Paul Eggert