[tz] Looking for details on timezones “right/…”

[Jürgen Appel]

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
> counted.
> 
> 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
> seconds.

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 
second.

> 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).

Cheers,
	Jürgen




Mobile: +45 25459049
Email: jap at dfm.dk
VAT: DK-29217939