Looking for details on timezones “right/…”
Hello, Today I stumbled upon timezone strings like “right/UTC”, “right/America/Jujuy”, and so forth, but I’m unable to find details on the meaning & classification of the “right/” here and how it relates to actual UTC and other timezones. I’d appreciate pointers or clarifications. Thank you kindly, Jens -- Jens Tröger https://savage.light-speed.de/
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. 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. 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. kre
On 1/17/23 11:57:53, 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.
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.
My experiments appear to show that TZ=right/* results in computing the time for zone "*" as if time() returned TAI-10 seconds. This is the current IBM recommended setting of hardware clocks on IBM mainframes, which ran on GMT until the inception of UTC in 1972 when TAI was 10 seconds ahead of UTC. IBM switched to running clocks at the atomic rate and introduced the 10-second offset in order to avoid a discontinuity. UTC is currently 37 (leap) seconds behind TAI. 529 $ uname -a Linux debian 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux 530 $ TZ=right/Universal date; TZ=Universal date Wed 18 Jan 2023 12:23:07 AM UTC Wed 18 Jan 2023 12:23:34 AM UTC 531 $ I have not experimented with TZ=right/* for dates prior to 1972. <http://leapsecond.com/java/gpsclock.htm> -- gil
On Tue 2023-01-17T17:56:17-0700 Paul Gilmartin via tz hath writ:
I have not experimented with TZ=right/* for dates prior to 1972. <http://leapsecond.com/java/gpsclock.htm>
IBM should assume no leap seconds, but because the old UTC frequency offset between 1970 and 1972 was 300e-10 that means at 1970 the difference TAI-UTC was 8.000082 s as shown in https://www.ucolick.org/~sla/leapsecs/deltat.html#amscidelt.png "right" timezones assume a unix system clock which was TAI - 10 s at 1970 and that SI seconds have been counted since at 1970, but that is not how people actually set their clocks. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
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
Date: Thu, 19 Jan 2023 15:17:09 +0000 From: =?utf-8?B?SsO8cmdlbiBBcHBlbA==?= via tz <tz@iana.org> Message-ID: <5648489.DvuYhMxLoT@dfm-3333-jap> | Or in other words: In the 'right' format, all seconds on your computer are | actually SI seconds of correct and identical duration That's correct, if you have a system which counts true UTC time. That's not anything POSIX defined. | and timestamps are strictly monotonic. That's no more or less true for UTC or POSIX time. When running normally each is monotonic, but in either form, the clock can always be set backwards, making timestamps non-monotonic. [It isn't worth wasting time here going into whether or not it makes sense to ever just call time (or anything else) "monotonic" as such, it is clear what the intended meaning is - but because of that the difference between monotonic and strictly monotonic is completely meaningless in this context. But in most systems, timestamps are not in any sense strictly monotonic, it is usually possible for two events to occur close enough together that the representation used to mark the timestamp cannot distinguish the two, and so the two timestamps appear identical, even though one occurred after the other - there are some systems which prevent that by arbitrarily altering one, so that it represents a different value, but on those systems accuracy is sacrificed to make that happen for no particularly good reason in most cases.] | All the leap seconds and their issues are pushed towards | the functions that convert POSIX-time to displayed local time That, as stated, makes no sense. If you have POSIX-time there are no leap seconds, or their issues, to deal with, they simply do not exist. In all cases, converting timestamps into something that can be displayed as local time is "pushed towards the functions...", the kernel just counts seconds (of one type or another) and everything else is handled by a library function (which is where the timezone files, including the right/* ones when they're available and being used) are used. | (same like | daylight savings time, where time jumps of hours cause no problems). The way that POSIX systems deal with leap seconds varies, in some there's a "second" which by most normal measures lasts for 2 seconds (the clock sits at xx:59:59 or xx:00:00 (where xx depends upon your timezone, and the first 59 or 00 will be different for zones not an even number of hours from UTC) for longer than it otherwise would. In other systems, there might be 1000 (or some other arbitrary number) of seconds before, after, or surrounding midnight UTC which are each 1/1000 (1ms) (in that case) longer or shorter than "normal" seconds. Other variations are possible. And I wouldn't ever say that any time variations or discontinuities cause no problems - whether they have a noticeable effect or not entirely depends upon what you're trying to do with the time, and how you're doing it. That applies to all of them (but the circumstances differ.) | 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 Again, nothing related to calculating with times is ever that simple. Certainly if all seconds are of precisely equal length, then it is easier to calculate accurate (relatively short) durations, than it is if the length of a second is varying slightly. On the other hand, if you want to calculate the durations on the scale of days or months (where noon Jan 5 is exactly 10 days after noon Dec 26 of the previous year) then if a leap second occurred at the end of Dec 31, simply subtracting the timestamps, and converting to days/hours/... would tell you the difference is 10 days and a second - one would need to account for leap seconds if you're using fixed length seconds which include leap seconds to match up times. Nothing about calculating times is ever nearly as easy as it seems, nor is any system for doing so obviously right, and all others obviously wrong, unless you only have one specific application (or perhaps type of application) in mind. If there were, we'd all be using that system, and there would be no variations of debate at all. Time seems simple - it is usually the first thing we learn how to measure as children (so it must be easy, right?) It isn't, time is the most complex and hard to deal with measurement system of any that exist. | In other words, the 'right/*' zones are useful, if you need time stamps | with one second accuracy or better. Sorry, but stated as blatantly as that, that's nonsense. Everything is far more complex than such a simple statement can possibly account for. | If you can tolerate up to a few dozens seconds inaccuracy That's nonsense too, unless you're attempting (for some bizarre reason) to calculate second counts over periods of (currently) about 50 years. There are a few applications where that kind of thing is needed, but it is very rare. | [...] the 'normal' zones are fine. Since most of us (here anyway) are using POSIX based systems (or similar) and have been doing that for a long time now, and almost everything works just like we'd expect it to (and if the timestamp on something that occurred close to a leap second is slightly less accurate than it could be, we mostly don't care, as it affects almost nothing), I'd suggest that the normal zones are fine, for almost everyone, regardless of any other constraints. Not everyone, that's true - but if you really need the right/* timezones, then you wouldn't be asking about them in these messages. That is, if someone is here asking what those right/* timezones are for, then the best, simplest, answer, is almost certainly "just ignore them". The people who are doing things which really need more precise long term, tend to know what they need, and if were to ask any question here it would be "How do I set things up so ...?" rather than "what are these for?" kre
Thank you, Robert, for the explanation! I asked because I was using Hypothesis to generate test data for a function I had written, and some of the generated test data contained the prefixes: https://hypothesis.readthedocs.io/en/latest/data.html#hypothesis.strategies.... In one particular instance some function runs failed with these prefixed timezones, and it turned out that the host which ran the tests did not have these timezones installed. That’s how I stumbled upon these prefixes… and then wasn’t able to find them documented. So, I appreciate your sharing some information, thank you! This raises an interesting point, though: suppose I receive a “genuine UTC” timestamp (i.e. produced on a machine with right/UTC timezone) and then I read that timestamp on a POSIX machine (i.e. with posix/UTC or just UTC timezone) — there is a slim chance that my timestamp has now shifted by one second, correct? And could that be exploited 🤔 With many greetings, Jens PS: Is there a public link available to this email thread?
On Jan 18, 2023, at 04:57, Robert Elz <kre@munnari.OZ.AU> 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.
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.
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.
kre
-- Jens Tröger https://savage.light-speed.de/
On 1/28/23 21:11:34, Jens Tröger via tz wrote:
This raises an interesting point, though: suppose I receive a “genuine UTC” timestamp (i.e. produced on a machine with right/UTC timezone) and then I read that timestamp on a POSIX machine (i.e. with posix/UTC or just UTC timezone) — there is a slim chance that my timestamp has now shifted by one second, correct? And could that be exploited 🤔
No good explanation -- I'd expect either 27 seconds or 0.
PS: Is there a public link available to this email thread?
Follow the links (no registration required) on: <https://www.iana.org/time-zones>. -- gil
participants (6)
-
Jens Tröger -
Jürgen Appel -
Paul Gilmartin -
Paul Gilmartin -
Robert Elz -
Steve Allen