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.