https://mm.icann.org/pipermail/tz-announce/2023-March/000079.html
> This release's code and data are identical to 2023a. In other words,
> this release reverts all changes made in 2023b other than commentary,
> as that appears to be the best of a bad set of short-notice choices
> for modeling this week's daylight saving chaos in Lebanon.
Version 2022f doesn't build on Darwin because its detection of whether
getrandom is available doesn't work. This has been fixed upstream, and
we can pull in the patches.
* Additional make flags are needed since some functions do not exist
or have different names or parameters on Windows.
* When compiling for Windows, GCC implicitly adds a `.exe` suffix to
the output file name. A patch is needed for the `install` target
to locate and install the correct files.
* The tzdata Makefile contains `zic` and `ZIC` variables. The former
refers to the path of the program to execute, while the latter
invokes the former with additional arguments (it is defined as
`ZIC=$(zic) $(ZFLAGS)`, `ZFLAGS` is normally empty).
Previously, `ZIC` was overridden, potentially loosing `ZFLAGS`
arguments. This commit changes it to override `zic` instead.
* The `zic` program is built and installed as part of the package and
also executed during the build to translate time-related files. When
cross-compiling it means that two executables need to be compiled:
one to get installed and run on the host platform, and another to
run on the build platform. Instead of renaming files and building a
temporary executable for the build platform, this commit references
the build platform's `tzdata.bin` package and runs its `zic`
program.
The timezone dumps have switched to a "slim" format since 2020b.
This has broken various packages, including
- go 1.4 (used for bootstrapping)
- haskellPackages.tz
- libical
The "fat" format can still be generated, as this commit shows.
It seems to create files that are *mostly* the slim versions with
some more data attached.
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
Notable changes:
- Morocco switched to permanent +01 on 2018-10-27
- Volgograd moved from +03 to +04 on 2018-10-28
- Fiji ends DST 2019-01-13, not 2019-01-20
- Most of Chile changes DST dates, effective 2019-04-06
tzdata: fetch over https
Notable recent changes:
- Northern Cyprus resumed EU rules starting 2017-10-29.
- Namibia will switch from +01 with DST to +02 all year, affecting
UT offsets starting 2018-04-01.
- Sudan will switch from +03 to +02 on 2017-11-01.
- Tonga will not observe DST on 2017-11-05.
- Turks & Caicos will switch from -04 all year to -05 with US DST,
affecting UT offset starting 2018-11-04.
