[tz] Looking for details on timezones “right/…”
jap at dfm.dk
Thu Jan 19 15:17:09 UTC 2023
Dear Robert Elz,
On Tuesday, 17 January 2023 19:57:53 CET Robert Elz via tz wrote:
> Date: Sun, 15 Jan 2023 18:40:27 +0100
> From: =?utf-8?Q?Jens_Tr=C3=B6ger?= via tz <tz at iana.org>
> Message-ID: <2FB37B4F-3F85-4260-8C49-D770591075C6 at light-speed.de>
> | Today I stumbled upon timezone strings like “right/UTC”,
> Many systems don't bother installing those, as they're not usually
> very useful on POSIX systems.
> | I’m unable to find details on the meaning & classification of the
> | “right/” here and how it relates to actual UTC and other timezones.
On https://data.iana.org/time-zones/tz-link.html, there are a few lines:
"The tz code and data support leap seconds via an optional "right"
configuration where a computer's internal time_t integer clock counts every
TAI second, as opposed to the default "posix" configuration where the internal
clock ignores leap seconds. The two configurations agree for timestamps
starting with 1972-01-01 00:00:00 UTC (time_t 63 072 000) and diverge for
timestamps starting with time_t 78 796 800, which corresponds to the first
leap second 1972-06-30 23:59:60 UTC in the "right" configuration, and to
1972-07-01 00:00:00 UTC in the "posix" configuration. In practice the two
configurations also agree for timestamps before 1972 even though the
historical situation is messy, partly because neither UTC nor TAI is well-
defined for sufficiently-old timestamps."
> The right/* zones convert genuine UTC (that is, the time that occasionally
> steps 23:59:58 23:59:59 23:59:60 00:00:00 00:00:01) with leap seconds
> That's not what you get in a posix time_t - there all days are 86400
> seconds long, no matter what, so a year is always (365 or 366) * 86400
Or in other words: In the 'right' format, all seconds on your computer are
actually SI seconds of correct and identical duration and timestamps are
strictly monotonic. All the leap seconds and their issues are pushed towards
the functions that convert POSIX-time to displayed local time (same like
daylight savings time, where time jumps of hours cause no problems).
In a system with 'right/*' zones, you can calculate the time difference
between two time instances simply by subtracting their time stamps, whereas in
'normal' systems you would have to account for leap seconds and, if the
timestamps of interest lie close to a leap second event, also on the details
on how your particular computer was dealing with them, i.e. when the NTP
client, its connected server, kernel or whatever was implementing the leap
> Only if you get (from somewhere) timestamps that are genuinely in UTC
> and not the POSIX approximation of it you get from gettimeofday() or
> clock_*() or stat(), ... are the right/* zones useful for anything at
> all. Unless you're an astronomer, or rocket engineer, the chances
> of that aren't high.
In other words, the 'right/*' zones are useful, if you need time stamps with
one second accuracy or better. Such accuracy is impossible with normal Posix
timestamps and 'normal' time zones as points of times within the leap seconds
cannot be mapped to a posix time stamp unambiguously.
If you can tolerate up to a few dozens seconds inaccuracy (or can live with up
to 2 seconds inaccuracy and do correct for leap seconds when calculating time
differences), the 'normal' zones are fine.
Please note that when using 'right/*' zones, timestamps e.g. on remote file
systems or USB-sticks generated by other systems will be interpreted
incorrectly (off by TAI-UTC-10s=27s currently).
Mobile: +45 25459049
Email: jap at dfm.dk
More information about the tz