764330ce0c
When formatting a timestamp the C API takes into account historical data
from tzdata, so it returns a date strings with a historically-correct
timezone abbreviation. However, tzname[] doesn't do this and it returns
the most recent abbreviation for the given zone.
For example, according to tzdata America/Cancun switched from EST/EDT to
CST/CDT on 1998-08-02:
Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 6:00u
-6:00 - CST 1981 Dec 26 2:00
-5:00 - EST 1983 Jan 4 0:00
-6:00 Mexico C%sT 1997 Oct 26 2:00
-5:00 Mexico E%sT 1998 Aug 2 2:00
-6:00 Mexico C%sT 2015 Feb 1 2:00
-5:00 - EST
So, formatting a timestamp from this time will yield a string with the
EDT timezone:
$ TZ=America/Cancun date -d "@902035565"
Sun Aug 2 01:26:05 EDT 1998
But using tzname[] (or strptime %z) shows the most recent data, where
America/Cancun uses EST (and doesn't use DST anymore, hence
tzname[1]=CDT that glibc remembers from the previous zone epoch):
$ TZ=America/Cancun ./tz
{EST, CDT}
This means that when we parse the formatted timestamp back we don't use
the historical timezone data, so we might end up with a different
offset:
TZ=America/Cancun, tzname[0]=EST, tzname[1]=CDT
@902035565603993 → Sun 1998-08-02 01:26:05 EDT → @902039165000000 → Sun 1998-08-02 01:26:05 CDT
src/test/test-time-util.c:452: Assertion failed: Expected "ignore" to be true
Aborted (core dumped) build-local/test-time-util
Instead of adding exceptions for every single timezone that switched
between different offsets in the past, let's address this a bit more
generally and skip the check if the parsed timezone doesn't match any of
the current timezones - this still keeps the check that the time
difference in such case is exactly one hour, so its effect should be
limited mostly to DST-related changes.
Resolves: #37684
(cherry picked from commit 7273d38335)
(cherry picked from commit 387df32dc2)
(cherry picked from commit 971b7789a9)
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release