Whither /usr/share/zoneinfo/right?
ISTR on Linux long ago, a subdirectory, /usr/share/zoneinfo/right, which used arguments not POSIX time but TAI. Was that a local hack, or was it removed, possibly because of uncertainty of future leap seconds? -- Thanks, gil
On 2025-12-28 10:59, Paul Gilmartin via tz wrote:
ISTR on Linux long ago, a subdirectory, /usr/share/zoneinfo/right, which used arguments not POSIX time but TAI. Was that a local hack, or was it removed, possibly because of uncertainty of future leap seconds?
It's still there, as a rarely-used option. By default current TZDB installs two files for Los Angeles: /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo-leaps/America/Los_Angeles and the latter file uses TAI. You can change the installation default by using 'make REDO=posix_only', 'make REDO=right_only', or 'make REDO=right_posix'; see the Makefile. Many platforms, like Debian, use an older directory organization, which puts the two Los Angeles files here instead: /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/right/America/Los_Angeles /usr/share/zoneinfo/posix/America/Los_Angeles where the first two names resolve to the same file (or to files with identical contents). An advantage of the older approach is that one can use 'TZ="right/America/Los_Angeles" to get TAI. A disadvantage is that functions like gmtime no longer work the way people expect; for example, TZ='right/America/Los_Angeles' gets you localtime with leap seconds, but gmtime without leap seconds, which leads to nonsense like this with GNU date: $ export TZ=right/America/Los_Angeles $ format='%Y-%m-%d %H:%M:%S %::z (%Z)' $ date "+$format"; date -u "+$format" 2025-12-28 18:04:48 -08:00:00 (PST) 2025-12-29 02:05:15 +00:00:00 (UTC) so the timestamps make it look like Los Angeles is 8 hours and 27 seconds behind UTC, even though the difference is correctly reported to be 8 hours exactly. This confusion breaks some applications. This is why TZDB 1998e changed to something more like the current approach; see commit 77e3dfe1a7b7e14e9f252fc628a5d405c35b6444 dated 1998-05-25 13:04:43 -0400 in the development repository. Effectively this means the TAI TZif files are inaccessible unless you use full pathnames in TZ, which I hope means you know the trouble you're getting into. Perhaps it is time to change the default REDO value in the Makefile to REDO='posix_only', as REDO='posix_right' isn't being used much and when it is used is probably being used incorrectly. Such a change to the default wouldn't affect platforms like Debian that continue to use the pre-1998 approach.
On 2025-12-28 19:12, Paul Eggert via tz wrote:
On 2025-12-28 10:59, Paul Gilmartin via tz wrote:
ISTR on Linux long ago, a subdirectory, /usr/share/zoneinfo/right, which used arguments not POSIX time but TAI. Was that a local hack, or was it removed, possibly because of uncertainty of future leap seconds?
It's still there, as a rarely-used option. By default current TZDB installs two files for Los Angeles:
/usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo-leaps/America/Los_Angeles
and the latter file uses TAI. You can change the installation default by using 'make REDO=posix_only', 'make REDO=right_only', or 'make REDO=right_posix'; see the Makefile.
Many platforms, like Debian, use an older directory organization, which puts the two Los Angeles files here instead:
/usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/right/America/Los_Angeles /usr/share/zoneinfo/posix/America/Los_Angeles
where the first two names resolve to the same file (or to files with identical contents).
An advantage of the older approach is that one can use 'TZ="right/America/ Los_Angeles" to get TAI. A disadvantage is that functions like gmtime no longer work the way people expect; for example, TZ='right/America/Los_Angeles' gets you localtime with leap seconds, but gmtime without leap seconds, which leads to nonsense like this with GNU date:
$ export TZ=right/America/Los_Angeles $ format='%Y-%m-%d %H:%M:%S %::z (%Z)' $ date "+$format"; date -u "+$format" 2025-12-28 18:04:48 -08:00:00 (PST) 2025-12-29 02:05:15 +00:00:00 (UTC)
so the timestamps make it look like Los Angeles is 8 hours and 27 seconds behind UTC, even though the difference is correctly reported to be 8 hours exactly. This confusion breaks some applications.
This is why TZDB 1998e changed to something more like the current approach; see commit 77e3dfe1a7b7e14e9f252fc628a5d405c35b6444 dated 1998-05-25 13:04:43 -0400 in the development repository. Effectively this means the TAI TZif files are inaccessible unless you use full pathnames in TZ, which I hope means you know the trouble you're getting into.
Perhaps it is time to change the default REDO value in the Makefile to REDO='posix_only', as REDO='posix_right' isn't being used much and when it is used is probably being used incorrectly. Such a change to the default wouldn't affect platforms like Debian that continue to use the pre-1998 approach.
Fedora, OpenSuSE and related distros release tzdata{,-posix,-right} under zoneinfo/{,posix,right}: https://src.fedoraproject.org/rpms/tzdata/blob/f43/f/tzdata.spec Debian and related release TAI including Etc/GMT[-+][0-9]+ in tzdata-legacy under zoneinfo/right. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On Dec 28, 2025, at 6:12 PM, Paul Eggert via tz <tz@iana.org> wrote:
It's still there, as a rarely-used option. By default current TZDB installs two files for Los Angeles:
/usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo-leaps/America/Los_Angeles
and the latter file uses TAI.
"Uses TAI" in what sense? The non-leap-second versions convert times represented as POSIX-style "seconds since the Epoch", which means "seconds since 1970-01-01 00:00:00 UTC, adjusted such that positive leap seconds aren't counted and additional seconds are added for negative leap seconds", to a local or UTC time corresponding to that value, and convert a "struct tm" corresponding to a local time to a value of that sort that would correspond to it. The leap-second versions convert times represented as "seconds that have elapsed since 1970-01-01 00:00:00 UTC", perhaps really meaning "... following the introduction of leap seconds" (not sure whether times before the introduction of the leap second would work down to the second). I'm not seeing whether either of those involve TAI. A clock that keeps TAI, which I guess would mean a clock that, on the first second of 1970-01-01 at the IERS Reference Meridian, would read 00:00:10, right?
On 2025-12-29 12:12, Guy Harris wrote:
On Dec 28, 2025, at 6:12 PM, Paul Eggert via tz <tz@iana.org> wrote:
/usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo-leaps/America/Los_Angeles
and the latter file uses TAI.
"Uses TAI" in what sense?
The non-leap-second versions convert times represented as POSIX-style "seconds since the Epoch", which means "seconds since 1970-01-01 00:00:00 UTC, adjusted such that positive leap seconds aren't counted and additional seconds are added for negative leap seconds", to a local or UTC time corresponding to that value, and convert a "struct tm" corresponding to a local time to a value of that sort that would correspond to it.
The leap-second versions convert times represented as "seconds that have elapsed since 1970-01-01 00:00:00 UTC", perhaps really meaning "... following the introduction of leap seconds" (not sure whether times before the introduction of the leap second would work down to the second).
I'm not seeing whether either of those involve TAI. A clock that keeps TAI, which I guess would mean a clock that, on the first second of 1970-01-01 at the IERS Reference Meridian, would read 00:00:10, right?
Not exactly, as the date was 1972-01-01 not 1970-01-01. From 1961 to 1972 UTC was adjusted in two different ways: mostly via frequency tweaking, but there were also small steps (what I would call "fractional leap seconds"). Although there was "atomic time", TAI in the current sense did not exist yet. The difference between "atomic time" and UTC was a discontinuous piecewise linear function. The "right" code ignores this mess entirely, and simply uses UTC before 1972. Like the "posix" code, it uses the somewhat-fuzzy "UT" for timestamps before UTC was standardized in 1963.
This follows up on my suggestion at the end of: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/LB4NTIQPNFCREDUF4... * Makefile (REDO): Default to posix_only, not posix_right. * NEWS: Mention this. --- Makefile | 2 +- NEWS | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index d314dcfe..d88760a8 100644 --- a/Makefile +++ b/Makefile @@ -170,7 +170,7 @@ TIME_T_ALTERNATIVES_TAIL = int_least32_t.ck uint_least32_t.ck \ # applications that are not leap second aware, and is closer to unsmeared # "right" time than unsmeared POSIX time is (e.g., 0.5 vs 1.0 s max error). -REDO= posix_right +REDO= posix_only # Whether to put an "Expires" line in the leapseconds file. # Use EXPIRES_LINE=1 to put the line in, 0 to omit it. diff --git a/NEWS b/NEWS index 96df4782..f645aafa 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,20 @@ News for the tz database Unreleased, experimental changes + Briefly: + The "right" TZif files are no longer installed by default. + + Changes to build procedure + + The Makefile no longer by default installs an alternate set + of TZif files for system clocks that count leap seconds. + Install with 'make REDO=posix_right' to get the old default, + which is rarely used in major downstream distributions. + If your system clock counts leap seconds (contrary to POSIX), + it is better to install with 'make REDO=right_only'. + This change does not affect the leapseconds file, which is still + installed as before. + Changes to code zic no longer generates a no-op transition when -- 2.51.0
participants (4)
-
Brian Inglis -
Guy Harris -
Paul Eggert -
Paul Gilmartin