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@iana.org> Message-ID: <2FB37B4F-3F85-4260-8C49-D770591075C6@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@dfm.dk VAT: DK-29217939