Update timezone data file to IANA 2025b #245
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ingested tooling from https://github.com/fmidev/smartmet-timezones (which uses the unlicence licence) and updated timezone data README so we have a means to regenerate the file that is documented.
Compared to IANA 2016c, the timezone information in 2025c no longer has a distinction between short and long names. For example, in 2016c America/Denver used MST for short, Mountain Standard Time for long but America/Boise used MST for both. This discrepancy was only present in a few time zones. With 2025c they both use MST for short and long, which also means that the built-in "Coordinated Universal Time" long form is now displayed as "UTC" like the short form. Now this could be considered a breaking change, so if there are concerns that we should maintain what was there before with manual fixups, let's discuss. If we merge this for a release it should come with a release note indicating long form time zone names now match short form in all cases.
While this does not fully resolve #67, it does help us maintain the time zone data file better. It would be much better to have the library use the system timezone data through standard library APIs than for us to provide one.