Hello, TZ, In: ftp://ftp.iana.org/tz/tz-link.html I read: The tz code and data support leap seconds via an optional "right" configuration, ... Empirically, this seems to assume time_t of TAI-10. This isn't GPS, which I understand to be TAI-19: http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_utc... TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock. I find a couple references to "zoneinfo/right" in Makefile and NEWS. Is there more complete documentation of "right" and its rationale elsewhere? Thanks, gil
On Nov 12, 2020, at 10:02 AM, Paul Gilmartin via tz <tz@iana.org> wrote:
In: ftp://ftp.iana.org/tz/tz-link.html I read: The tz code and data support leap seconds via an optional "right" configuration, ...
Empirically, this seems to assume time_t of TAI-10. This isn't GPS, which I understand to be TAI-19: http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_utc...
TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock.
I find a couple references to "zoneinfo/right" in Makefile and NEWS. Is there more complete documentation of "right" and its rationale elsewhere?
I don't know whether it's documented anywhere, but: "right" is intended to support converting times that are represented as seconds that have elapsed since January 1, 1970, 00:00:00 UTC - as opposed to be represented as "seconds since the Epoch", which means "seconds *except for leap seconds* that have elapsed since January 1, 1970, 00:00:00 UTC" - to year/month/day/hour/minute/second. I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX. gmtime() would convert such a time to UTC, with "second" possibly being > 59.
On Thu 2020-11-12T10:11:26-0800 Guy Harris hath writ:
I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX.
With the historical caveat that as of 1970 there was not yet any official document that specified the name UTC. Until 1974 UTC was jargon internal to time service bureaus. Most available sources of time used different terminology. -- 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
On Nov 12, 2020, at 10:34 AM, Steve Allen <sla@ucolick.org> wrote:
On Thu 2020-11-12T10:11:26-0800 Guy Harris hath writ:
I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX.
With the historical caveat that as of 1970 there was not yet any official document that specified the name UTC. Until 1974 UTC was jargon internal to time service bureaus. Most available sources of time used different terminology.
So what POSIX says in section 3 "Definitions": https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html is 3.150 Epoch The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC). and what it says in section A.3 "Definitions" of the Rationale: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html is Epoch Historically, the origin of UNIX system time was referred to as "00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually not a term acknowledged by the international standards community; therefore, this term, "Epoch", is used to abbreviate the reference to the actual standard, Coordinated Universal Time. with no indication of how they define "zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC)." Should there be a request for clarification of what they mean by that?
On 2020-11-12 9:13 PM, Guy Harris wrote:
On Nov 12, 2020, at 10:34 AM, Steve Allen <sla@ucolick.org> wrote:
On Thu 2020-11-12T10:11:26-0800 Guy Harris hath writ:
I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX. With the historical caveat that as of 1970 there was not yet any official document that specified the name UTC. Until 1974 UTC was jargon internal to time service bureaus. Most available sources of time used different terminology. So what POSIX says in section 3 "Definitions":
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
is
3.150 Epoch
The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC).
and what it says in section A.3 "Definitions" of the Rationale:
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html
is
Epoch
Historically, the origin of UNIX system time was referred to as "00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually not a term acknowledged by the international standards community; therefore, this term, "Epoch", is used to abbreviate the reference to the actual standard, Coordinated Universal Time.
with no indication of how they define "zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC)."
Should there be a request for clarification of what they mean by that?
See IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) A.4 General Concepts https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html Section: A.4.16 Seconds Since the Epoch I believe Joe Gwinn may have something to say about this section. In many discussions I've encountered the point that the Posix "the epoch" shifts with respect to TAI and UTC is over looked or not made clear. Consider the following listing showing UTC and Posix times surrounding the first leap-second at 1972-06-30 23:59:60 (UTC): --------------------------------------------------------------------- UTC YMDhms.100nano Secs Posix LS << comment with leap-seconds Since Origin UTC1970 wrt (Posix time_t) UTC1972 Posix YMDhms.100nano Secs Posix LS << comment without leap-seconds Since Origin (86400 sec days) UTC1970 wrt (Posix time_t) UTC1972 --------------------------------------------------------------------- 1972-06-30 23:59:58.0000000 78796798.0000000 -63072000 00 1972-06-30 23:59:58.0000000 78796798.0000000 -63072000 00 1972-06-30 23:59:58.5000000 78796798.5000000 -63072000 00 1972-06-30 23:59:58.5000000 78796798.5000000 -63072000 00 1972-06-30 23:59:59.0000000 78796799.0000000 -63072000 00 1972-06-30 23:59:59.0000000 78796799.0000000 -63072000 00 1972-06-30 23:59:59.5000000 78796799.5000000 -63072000 00 1972-06-30 23:59:59.5000000 78796799.5000000 -63072000 00 1972-06-30 23:59:60.0000000 78796800.0000000 -63072000 00 << leap-second 1972-07-01 00:00:00.0000000 78796800.0000000 -63072000 00 << NTP Freeze 1972-06-30 23:59:60.5000000 78796800.5000000 -63072000 00 << leap-second 1972-07-01 00:00:00.0000000 78796800.0000000 -63072000 00 << NTP Freeze 1972-07-01 00:00:00.0000000 78796801.0000000 -63072000 01 << TAI-UTC - 10 = leap-seconds 1972-07-01 00:00:00.0000000 78796800.0000000 -63071999 01 << Posix origin wrt UTC1972 1972-07-01 00:00:00.5000000 78796801.5000000 -63072000 01 << TAI-UTC - 10 = leap-seconds 1972-07-01 00:00:00.5000000 78796800.5000000 -63071999 01 << Posix origin wrt UTC1972 1972-07-01 00:00:01.0000000 78796802.0000000 -63072000 01 << TAI-UTC - 10 = leap-seconds 1972-07-01 00:00:01.0000000 78796801.0000000 -63071999 01 << Posix origin wrt UTC1972 1972-07-01 00:00:01.5000000 78796802.5000000 -63072000 01 << TAI-UTC - 10 = leap-seconds 1972-07-01 00:00:01.5000000 78796801.5000000 -63071999 01 << Posix origin wrt UTC1972 The first line of each pair shows the leap-second compensated YMDhms and associated values. The second line shows the uncompensated Posix YMDhms and values. The pairs of values increment by 1/2 second at 100-nanosecond resolution. The 3rd column shows the seconds since the Posix origin, the 4th the Posix origin with respect to (wrt) UTC1972, and the 5th the leap-second value. UTC1972 is the initial alignment point between TAI and UTC: 441763210s (TAI) = 1972-01-01 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) The Posix "the epoch" is defined as 1970-01-01 00:00:00 (UTC), exactly 63072000 seconds (two years, 365 days x 2 = 730 days x 86400 seconds = 63072000s) before UTC1972, here called UTC1970. Before the leap-second the UTC and Posix YMDhms, seconds since UTC1970 (Posix time_t) and the Posix origin wrt UTC1972 are equal. The YMDhms representation of the Posix time_t count of zero 1970-01-01 00:00:00 (UTC). Origin of Posix time_t = 0 = 1970-01-01 00:00:00 (UTC), 63072000s before UTC1972 |------------------ > After the leap-second the origin of the Posix count (origin of time_t) has shifted by one second to 1970-01-01 00:00:01 (UTC) due to the omitted count at the freeze imposed on the Posix count by NTP. Origin of Posix time_t = 0 = 1970-01-01 00:00:01 (UTC), 63071999s before UTC1972 |>|---------------- > After the leap-second is omitted the Posix time_t is left as zero-based uninterrupted incrementing count but its origin has shifted by one second with respect to UTC. This offset increases by one second for each leap-second, currently 27 seconds. David Mills, the inventor of NTP, explains leap-seconds and the NTP and Posix timescales in: The NTP Timescale and Leap Seconds https://www.eecis.udel.edu/~mills/leap.html I draw your attention to the follow extract: 3. How NTP and POSIX Reckon with Leap Seconds "... Another way to describe this is to say there are as many NTP or POSIX timescales as historic leap seconds. In effect, a new timescale is reestablished after each new leap second. Thus, all previous leap seconds, not to mention the apparent origin of the timescale itself, lurch backward one second as each new timescale is established. ..."
On Nov 12, 2020, at 7:00 PM, Brooks Harris <brooks@edlmax.com> wrote:
See IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) A.4 General Concepts https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html Section: A.4.16 Seconds Since the Epoch
Yes, I have - many times. (Back when I was at Sun, the question of what to do with leap seconds was under discussion; Sun was trying to get leap second support to be allowed, but we lost that battle.)
I believe Joe Gwinn may have something to say about this section.
I don't know about Joe Gwinn, but I *do* know that Doug Gwyn was pushing the ANSI C committee to allow tm_sec to be > 59; he was successful in doing so. But none of this addresses what I was discussing in the message to which you're responding, which is "can one speak of UTC for a date and time in 1970 and, if so, how does that relate to the current specification of UTC?" For what it's worth, the Wikipedia page for Coordinated Universal Time: says: The coordination of time and frequency transmissions around the world began on 1 January 1960. UTC was first officially adopted as CCIR Recommendation 374, Standard-Frequency and Time-Signal Emissions, in 1963, but the official abbreviation of UTC and the official English name of Coordinated Universal Time (along with the French equivalent) were not adopted until 1967. The system has been adjusted several times, including a brief period where the time-coordination radio signals broadcast both UTC and "Stepped Atomic Time (SAT)" before a new UTC was adopted in 1970 and implemented in 1972. This change also adopted leap seconds to simplify future adjustments. This CCIR Recommendation 460 "stated that (a) carrier frequencies and time intervals should be maintained constant and should correspond to the definition of the SI second; (b) step adjustments, when necessary, should be exactly 1 s to maintain approximate agreement with Universal Time (UT); and (c) standard signals should contain information on the difference between UTC and UT." Presumably 1970-01-01 00:00:00 UTC is in "the new UTC".
UTC1972 is the initial alignment point between TAI and UTC: 441763210s (TAI) = 1972-01-01 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC)
The Posix "the epoch" is defined as 1970-01-01 00:00:00 (UTC), exactly 63072000 seconds (two years, 365 days x 2 = 730 days x 86400 seconds = 63072000s) before UTC1972, here called UTC1970.
So that's 1970-01-01 00:00:00 (UTC, meaning "the new UTC, extended backwards to 1970, with no leap seconds added or removed prior to 1972").
On Fri 2020-11-13T18:25:30-0800 Guy Harris hath writ:
For what it's worth, the Wikipedia page for Coordinated Universal Time:
Is not consistent with the original source documents. The wikipedia article is consistent with some historical summaries. Authors of those summaries did not respond when I pointed to the original sources and asked where they supported the summary. When a senator, prime minister, or general asks their national time service bureau if they can tell what time it is, the staff of the time service bureau say "Yes." They do not point the bureaucrats at documents like Bulletin Horaire, Circular D, and now Circular T which exist in order to document how wrong the time service bureau was last month and which contain the clues about how staff at other time service bureaus disagree with the way that their national laboratory has been determining what time it is. -- 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
On 2020-11-13 9:25 PM, Guy Harris wrote:
On Nov 12, 2020, at 7:00 PM, Brooks Harris <brooks@edlmax.com> wrote:
See IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) A.4 General Concepts https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html Section: A.4.16 Seconds Since the Epoch Yes, I have - many times. (Back when I was at Sun, the question of what to do with leap seconds was under discussion; Sun was trying to get leap second support to be allowed, but we lost that battle.)
I believe Joe Gwinn may have something to say about this section. I don't know about Joe Gwinn, but I *do* know that Doug Gwyn was pushing the ANSI C committee to allow tm_sec to be > 59; he was successful in doing so.
But none of this addresses what I was discussing in the message to which you're responding, which is "can one speak of UTC for a date and time in 1970 and, if so, how does that relate to the current specification of UTC?"
For what it's worth, the Wikipedia page for Coordinated Universal Time:
says:
The coordination of time and frequency transmissions around the world began on 1 January 1960. UTC was first officially adopted as CCIR Recommendation 374, Standard-Frequency and Time-Signal Emissions, in 1963, but the official abbreviation of UTC and the official English name of Coordinated Universal Time (along with the French equivalent) were not adopted until 1967.
The system has been adjusted several times, including a brief period where the time-coordination radio signals broadcast both UTC and "Stepped Atomic Time (SAT)" before a new UTC was adopted in 1970 and implemented in 1972. This change also adopted leap seconds to simplify future adjustments. This CCIR Recommendation 460 "stated that (a) carrier frequencies and time intervals should be maintained constant and should correspond to the definition of the SI second; (b) step adjustments, when necessary, should be exactly 1 s to maintain approximate agreement with Universal Time (UT); and (c) standard signals should contain information on the difference between UTC and UT."
Presumably 1970-01-01 00:00:00 UTC is in "the new UTC".
UTC1972 is the initial alignment point between TAI and UTC: 441763210s (TAI) = 1972-01-01 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC)
The Posix "the epoch" is defined as 1970-01-01 00:00:00 (UTC), exactly 63072000 seconds (two years, 365 days x 2 = 730 days x 86400 seconds = 63072000s) before UTC1972, here called UTC1970. So that's 1970-01-01 00:00:00 (UTC, meaning "the new UTC, extended backwards to 1970, with no leap seconds added or removed prior to 1972").
That is my understanding, yes. You have to be careful in these sorts of discussions. For purposes of civil time and computer timekeeping I might call this "Proleptic UTC", that is, as you say "extended backwards to 1970, with no leap seconds added or removed prior to 1972", and that this extension is treated in whole integral seconds. Thus: 378691210s (TAI) = 1970-01-01 00:00:10 (TAI) = 1970-01-01T00:00:00 (UTC) = Posix "the epoch" While the Posix time specification is somewhat vague (and, as I understand it, *intentionally* vague to accommodate legacy systems) the NTP specification is more clear. rfc5905 https://tools.ietf.org/html/rfc5905 6. Data Types " In the date and timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should be noted that strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost." Thus NTP Era 0 is 2272060800s (72 years including leap years * 86400s) before UTC1972 (which is also before the TAI origin at 1958-01-01 00:00:00 (TAI)): -1830297600s (TAI) = 1900-01-01 00:00:10 (TAI) = 1900-01-01T00:00:00 (UTC) David Mills explains this in some detail: The NTP Timescale and Leap Seconds https://www.eecis.udel.edu/~mills/leap.html Note, importantly, others concerned with high resolution timekeeping for other purposes, such as astronomy and geo-sciences where historical representations are critical, may insist that the term "Proleptic UTC" must include the small frequency and partial second adjustments made during the development period of atomic time and what became know as UTC from approx 1960 to the final unique adjustments that took effect on UTC1972 together with application of extrapolated leap-seconds derived from Delta T and other sources into the deep past. As Steve Allen has said in this thread "The answer depends on the needs of the application.". I believe here we are concerned with "civil time and computer timekeeping" and thus constrained to using proleptic timescales in integral seconds.
Brooks Harris <brooks@edlmax.com> wrote:
While the Posix time specification is somewhat vague (and, as I understand it, *intentionally* vague to accommodate legacy systems) the NTP specification is more clear.
To a limited extent. NTP is all about distributing the current time so the exact meaning of historical timestamps is largely irrelevant. NTP has the same issue as POSIX time that it skips leapseconds: there is a fixed numerical offset between NTP and POSIX time, stated in RFC 5905 figure 4: | 1 Jan 1970 | 40,587 | 0 | 2,208,988,800 | First day UNIX | | 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th | | | | | | Century | $ TZ=UTC date -d @$((3155587200 - 2208988800)) +%FT%TZ 1999-12-31T00:00:00Z So, like POSIX time, you can't tell which UTC time corresponds to an NTP timestamp around a leapsecond without some extra information. The definition of POSIX time makes it clear that a positive leap second gets the same time_t value as the following second, but NTP does not specify how leapseconds are labelled to that level of detail. The NTP wire protocol has two leap second warning bits, but their values are not synchronized to the leap second, so they cannot be used to disambiguate the timestamp. Insted they relate to how the NTP daemon and the kernel clocks communicate state: the NTP leap second warning bits correspond to the ntp_adjtime() STA_INS and STA_DEL flags, but to disambiguoate timestamps you need the return values TIME_OOP or TIME_WAIT which are not present on the wire. An NTP server will continue returning the same leap warning flags through the leap second (while ntp_adjtime would return TIME_OOP or TIME_WAIT) until the next time it adjusts the clock and resets the leap state. https://www.freebsd.org/cgi/man.cgi?ntp_adjtime The upshot is that you can't use NTP as a good example of how to label timestamps. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ St Davids Head to Great Orme Head, including St Georges Channel: Southwest 6 or 7, increasing gale 8 at times. Moderate or rough, but slight or moderate northeast of Anglesey. Occasional rain or drizzle. Moderate or good, occasionally poor.
On Thu 2020-11-12T18:13:54-0800 Guy Harris hath writ:
So what POSIX says in section 3 "Definitions":
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
is
3.150 Epoch
The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC).
and what it says in section A.3 "Definitions" of the Rationale:
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html
is
Epoch
Historically, the origin of UNIX system time was referred to as "00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually not a term acknowledged by the international standards community; therefore, this term, "Epoch", is used to abbreviate the reference to the actual standard, Coordinated Universal Time.
Although not specified by any standards nor recommendations, the term "Coordinated Universal Time" did then exist within the time service bureaus, and that has a precise meaning, and because Germany had not yet moved to stop broadcasting old UTC it was a legal time everywhere. It is also the case that the calendar day based on the rotation of the earth is not acknowledged by the international standards community, but at no point have the committees had the balls to create a recommendation or standard which changes the definition of the calendar day such that it is unrelated to the rotating earth. Such an action would violate national laws. This is the reason we have leap seconds. It is also the case that the CGPM, overseeing the SI, has never abrogated the definition of the mean solar second as 1/86400 of the calendar day. This is because they never defined it as such, so they cannot undefine it as such. In most places other than Germany (where it was deemed explicitly illegal) the mean solar second still has legal existence distinct from the SI second.
Should there be a request for clarification of what they mean by that?
No, mostly because of https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag... where POSIX has the word "approximates" and the phrase "relationship with the current actual time is implementation-defined." Also because that goes down the rabbit hole into places where the writers of the official (and, upon inspection of the source documents, pedantically incorrect) definitions for the time scales we use dared not go lest they give national bureaucrats clues about how there are two qualitatively different meanings for "time". -- 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
On 13 Nov 2020, at 02:13, Guy Harris <gharris@sonic.net> wrote:
On Nov 12, 2020, at 10:34 AM, Steve Allen <sla@ucolick.org> wrote:
On Thu 2020-11-12T10:11:26-0800 Guy Harris hath writ:
I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX.
With the historical caveat that as of 1970 there was not yet any official document that specified the name UTC. Until 1974 UTC was jargon internal to time service bureaus. Most available sources of time used different terminology.
So what POSIX says in section 3 "Definitions":
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
is
3.150 Epoch
The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC).
and what it says in section A.3 "Definitions" of the Rationale:
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html
is
Epoch
Historically, the origin of UNIX system time was referred to as "00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually not a term acknowledged by the international standards community; therefore, this term, "Epoch", is used to abbreviate the reference to the actual standard, Coordinated Universal Time.
with no indication of how they define "zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC)."
Should there be a request for clarification of what they mean by that?
It's messy. When I was looking into this a few years ago I was looking at various different parts of the standards to try to find out what was actually meant. The definition of the epoch gets blurred depending on where you look :) If you do "date -d @0" on a Unix machine it does indeed say it's right at the start of 1970 ("Thu 1 Jan 01:00:00 BST 1970" here in the UK :)). However. If the wall clock time for the Unix Epoch is not the stroke of midnight -- it *moves*. And it moves because a day is exactly 86400 seconds. In the real world though there have been 27 (I think) days between the Posix Epoch and now where a day was 86401 seconds. If you use a right timezone on Linux then you have to live with minor but irritating problems with programs that implicitly assume the Posix day length. For those applications that really don't work unless you're using a right/ timezone, that minor annoyance is a price worth paying. jch
On Fri, Nov 13, 2020 at 4:12 PM John Haxby <john.haxby@oracle.com> wrote:
If the wall clock time for the Unix Epoch is not the stroke of midnight -- it *moves*. And it moves because a day is exactly 86400 seconds. In the real world though there have been 27 (I think) days between the Posix Epoch and now where a day was 86401 seconds.
If you use a right timezone on Linux then you have to live with minor but irritating problems with programs that implicitly assume the Posix day length. For those applications that really don't work unless you're using a right/ timezone, that minor annoyance is a price worth paying.
Most applications that are neither astronomical nor navigational find it convenient to treat the nominal time since epoch as "86400 times the number of days since 1 January 1970 + the number of elapsed seconds in the current day." The reason for ignoring leap seconds is that a great many applications deal with *civil* dates and times in the future, and it is impossible to predict more than a year or two in advance when a leap second might occur. As a practical matter, this definition causes clock anomalies when leap seconds do occur. What a great many services, including Google, do with the discontinuity is to adopt a 'leap smear'. When a leap second is inserted, the system clock is allowed to run at some figure such as 99.99% of its correct speed, so that over the next 10,000 seconds (2h 46m 40s) the clock will again be synchronized. (A similar technique could deal with a 59-second minute, but this has never occurred). More recently, the time constant has been changed from 1/10000 to 1/86400, to provide greater interval accuracy at the expense of smearing the leap second over an entire day. This technique provides for a clock that advances monotonically, can be synchronized among systems, and still keeps pace with civil time, at the disadvantage of having interval measurements correct only to plus or minus 0.01% while a smear is taking place. Since all systems with synchronized clocks smear at the same rate, this takes care of database synchronization even to sub-second precision, and is pretty much adequate for all human-facing times; only scientific and navigational applications that require more precision in intervals need worry about the leap seconds. A POSIX system that doesn't use 'right' will, in fact, have this behaviour by default if NTP is running. An attempt to synchronize with a time source at a lower stratum will show that the system's clock is off by a second, and the phase-locked loop will drift it to bring it back into synchronization. The convenience of this technique for proleptic calculation of civil times, and the fact that it allows for precise synchronization of one system with another, was thought by the POSIX people to outweigh the disadvantage of briefly being up to one second (by an amount that can be determined by a relatively simple calculation) out of step with respect to the heavens, the atomic clocks and the GPS constellation. Some more sophisticated proposals have made the smear follow a cosine function rather than a linear one, so that there is no discontinuity in the rate at which the clock is ticking, as well as no discontinuity in the clock's reading This scheme has been proposed formally a number of times, without committee action: Original proposal: https://tools.ietf.org/html/draft-kuhn-leapsecond-00 UTC-SLS (linear smearing with 1000 second time constant _before_ the leap second): https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ Tcl programming language, 2000 (1000 second time constant, _after_ the leap second): https://core.tcl-lang.org/tips/doc/trunk/tip/7.md Google 2008 (cosine smear, 20 hour time constant, before the leap second): https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.... Google 2012, 2015, 2016 (20 hour linear smear, centered on the leap second): https://cloudplatform.googleblog.com/2015/05/Got-a-second-A-leap-second-that... Google's current implementation: https://developers.google.com/time/smear Bloomberg smear (2000 second linear smear, after the leap second, widely used in the financial industry): https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_Dece... Meinberg Funkuhren smear (configurable, used on several models of NTP primary clocks): https://www.meinbergglobal.com/download/burnicki/Leap%20Second%20Smearing%20... Given that both the Meinberg and Google libraries can recover TAI from smeared 'seconds from the Epoch', the pull for 'right' time has very much lessened in the couple of decades that it's been around. -- 73 de ke9tv/2, Kevin
On Nov 13, 2020, at 7:38 PM, Kevin Kenny <kevin.b.kenny@gmail.com> wrote:
On Fri, Nov 13, 2020 at 4:12 PM John Haxby <john.haxby@oracle.com> wrote: If the wall clock time for the Unix Epoch is not the stroke of midnight -- it *moves*. And it moves because a day is exactly 86400 seconds. In the real world though there have been 27 (I think) days between the Posix Epoch and now where a day was 86401 seconds.
If you use a right timezone on Linux then you have to live with minor but irritating problems with programs that implicitly assume the Posix day length. For those applications that really don't work unless you're using a right/ timezone, that minor annoyance is a price worth paying.
Most applications that are neither astronomical nor navigational find it convenient to treat the nominal time since epoch as "86400 times the number of days since 1 January 1970 + the number of elapsed seconds in the current day." The reason for ignoring leap seconds is that a great many applications deal with *civil* dates and times in the future, and it is impossible to predict more than a year or two in advance when a leap second might occur.
These days, most of my software work involves an application where the ideal time stamp is "seconds that have elapsed since the Epoch, *including* leap seconds", because 1) users might want to know both 1) absolute times and 2) delta times in seconds and 2) times are 99.999999999999999999% likely to be times in the past, so there's no issue with the inability to predict leap seconds in the future. That application is "capturing network packets and saving them to a file, and then analyzing those files", i.e., in my case, libpcap, tcpdump, and Wireshark. It would be Very Nice Indeed if: packet capture mechanism could time-stamp packets with "seconds that have elapsed since the Epoch, *including* leap seconds"; APIs existed to convert those time stamps to year/month/day/hour/minute/second/fraction of a second. (Extra credit for those APIs being able to take a tzdb ID, or a handle returned by an API that takes a tzdb ID, so that if somebody wants to know what time it was in Berlin when the packets arrived, even if they're in Adelaide when they're analyzing the packets.) (And, yes, that should also involve a way of indicating what type of time stamp packets received on a particular adapter, e.g. "POSIX timestamps" vs. "all seconds since the Epoch" time stamps", so the program know how to convert them to year/month/day/hour/minute/second/fraction. I need to update the pcapng spec for that.) That doesn't mean *all* APIs need to work that way - just provide, in addition to APIs using POSIX time stamps, APIs using "all seconds since the Epoch" time stamps. (One possibility would be to have the "take a tzdb ID and return a handle" API also take an indication of whether time stamps should be treated as POSIX or "all seconds since the Epoch"; "if the tzdb ID has right/ prepended to it, it's all seconds since the Epoch, otherwise it's POSIX time" is one option.) This provides a clock that, as long as the clock is adjusted by doing adjtime()-style adjustment (don't turn the clock forward, temporarily speed it up until it's where you want it to be, and don't turn the clock backward, temporarily slow it down until it's where you want it to be), is monotonic, and that, modulo the clock being off, can be used to compute time deltas between packets without leap seconds causing incorrect deltas. (It's better if the packet gets time stamped on arrival as close either to the time the first bit appears or the time the last bit appears, and time stamped on transmission as close either to the time the first bit is put on the wire or the time when the last bit is put on the wire, which probably requires adapters that can do that.)
On Fri 2020-11-13T22:38:56-0500 Kevin Kenny hath writ:
Most applications that are neither astronomical nor navigational find it convenient to treat the nominal time since epoch as "86400 times the number of days since 1 January 1970 + the number of elapsed seconds in the current day." The reason for ignoring leap seconds is that a great many applications deal with *civil* dates and times in the future, and it is impossible to predict more than a year or two in advance when a leap second might occur.
Not "Most". All. Even in astronomy and navigation. Every technical person involved in the process knew this in 1970 when the decision was made to implement leap seconds. Every technical system continued to use an underlying continous count of seconds, SI seconds of TAI for radio broadcasts and automated navigation systems, and mean solar seconds of UT for almanacs of astronomical phenomena. If the underlying count of seconds in POSIX were based on TAI then leap seconds do not cause more trouble for planning future civil events than is already caused by bureaucrats changing time zones. Technically it was only feasible to run radio broadcast, collision avoidance, or any laboratory systems using SI seconds. Legally it was necessary for calendar days to remain based on watching the sun in the sky. Each delegate to the international science and regulatory meetings could not introduce nor support a recommendation which would have been illegal in their country. The proceedings of the 1970 IAU referenced earlier include Gerhard Becker remarking that action was needed in order to make atomic-based time legal in all countries. He had already been saying, and would continue to say, the same at other meetings for several years, but he never got any traction. I suspect that is because the urgent need to create leap seconds was caused by the legislation Becker introduced in Germany which made old UTC illegal. I think nobody else wanted to risk pointing out to other governments how atomic time differed from watching the sun in the sky lest some other government make atomic time explicitly illegal and thus poison the possibility for all radio time broadcasts to agree worldwide. Agreement of all radio broadcast time signals was the reason that the 1912 time conference was called, the reason that BIH had come into existence, and a primary goal of the international time committees ever since then. Of all the persons visible in that 1970 IAU meeting, and at all the other meetings of other agencies, only H.M. Smith expressed happiness about UTC with leap seconds, and that was in the context of having found something on which all governments could agree. Every other memoir by folks who were part of the process contains tones of regret. Regret about the situation that we find ourselves in because POSIX chose a simple solution based on what was legal and available. But also the only feasible option because, unfortunately, after the sourness of the 1970 decision all of the technical principals backed away from the issue. Nobody created a means of distributing the history of leap second information more robust than having the BIH send letters to the heads of national time service bureaus. -- 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
On 11/13/20 7:38 PM, Kevin Kenny wrote:
[Leap smearing has] been proposed formally a number of times, without committee action
Leap smearing is controversial, for reasons that echo the 1970 disputes that Steven Allen mentioned in this thread. For example, Internet RFC 8633 "Network Time Protocol Best Current Practices" section 3.7.1 states flatly that "Leap smearing MUST NOT be used for public-facing NTP servers" while acknowledging that some public-facing servers ignore this requirement - I assume this is a nod to Amazon and Google. It's a real lack of consensus.
On 2020-11-12, at 11:11:26, Guy Harris wrote:
I don't know whether it's documented anywhere, but:
That's unfortunate.
"right" is intended to support converting times that are represented as seconds that have elapsed since January 1, 1970, 00:00:00 UTC - as opposed to be represented as "seconds since the Epoch", which means "seconds *except for leap seconds* that have elapsed since January 1, 1970, 00:00:00 UTC" - to year/month/day/hour/minute/second.
Confirming my experiment. That's also the rationale for IBM z/OS TOD. Was UTC defined in 1970, or should it pedantically be GMT for 1970 and 1971; TAI-10 thereafter?
I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX.
gmtime() would convert such a time to UTC, with "second" possibly being > 59.
Assuming TZ=right/Universal. My experiments confirm all this. Thanks again, gil
On Thu 2020-11-12T12:11:52-0700 Paul Gilmartin via tz hath writ:
Was UTC defined in 1970, or should it pedantically be GMT for 1970 and 1971; TAI-10 thereafter?
Pedantically there are no answers which are universally true. During 1970 and 1971 (and a few years before) different time service bureaus were providing various different time scales with various different names in their radio broadcast time signals. US NBS provided two different broadcasts with different time scales (old UTC and stepped atomic time SAT). German PTB provided two different time scales at different times of day using the same transmitter (old UTC until that became illegal in Germany, thereafter SAT). During those years the terminology UTC was only known inside the time service service bureaus. As for GMT, the final observation using the Greenwich meridian circle was 1954-03-30. After that date there was no authority who could provide a definition of GMT. The last use of that term by almanacs was in 1959. The term GMT continued to be used by some time service bureaus, but in accord with CCIR recommendation 374 they were broadcasting the original form of what was internally known as UTC. On 1974-01-01 NBS WWV stations started announcing as UTC. In 1976 the IAU urged no further use of GMT. In 1978 the CCIR was informed that GMT was no longer used. In 1980 the CCITT specified UTC to replace GMT for all telecommunications activities. -- 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
On 11/12/20 11:50 AM, Steve Allen wrote:
Pedantically there are no answers which are universally true.
Yes, it's hard to summarize this in a way that's both useful (i.e., brief) and true (or at least true enough). I gave it a shot, though, by installing the attached proposed patch.
So https://www.bipm.org/en/bipm-services/timescales/tai.html says A practical scale of time for world-wide use has two essential elements: a realization of the unit of time and a continuous temporal reference. The reference used is International Atomic Time (TAI), a time scale calculated at the BIPM using data from some four hundred atomic clocks in over eighty national laboratories. In that context, what is a "time scale"? Does it assign an hour/minute/second value to each second? It then says TAI is a uniform and stable scale which does not, therefore, keep in step with the slightly irregular rotation of the Earth. For public and practical purposes it is necessary to have a scale that, in the long term, does. Such a scale is Coordinated Universal Time (UTC), which is identical with TAI except that from time to time a leap second is added to ensure that, when averaged over a year, the Sun crosses the Greenwich meridian at noon UTC to within 0.9 s. so UTC is also a "time scale". ITU-R Recommendation TF.460-6: http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pd... says A positive leap-second begins at 23h 59m 60s ... which suggests that *something* is assigning hour/minute/second values to seconds. It also says A positive or negative leap-second should be the last second of a UTC month ... suggesting that the clock is tied to a calendar in some fashion.
On Thu 2020-11-12T14:05:18-0800 Guy Harris hath writ:
In that context, what is a "time scale"? Does it assign an hour/minute/second value to each second?
A time scale assigns labels to points in time. TAI is the best effort for those points in time to be equidistant in a general relativistic reference frame that resembles the surface of the earth. For TAI those labels may be simply a continuous count of seconds, but it is traditional to give names based on civil calendars and clocks even though those TAI labels differ systematically from calendar days measured by watching the sky from the earth.
so UTC is also a "time scale".
Which shares the same second markers at TAI, but applies different labels that over the long run do not systematically differ from calendar days measured by watching the sky.
A positive or negative leap-second should be the last second of a UTC month ...
suggesting that the clock is tied to a calendar in some fashion.
The Gregorian calendar is used for UTC. -- 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
On 2020-11-12 5:05 PM, Guy Harris wrote:
So
https://www.bipm.org/en/bipm-services/timescales/tai.html
says
A practical scale of time for world-wide use has two essential elements: a realization of the unit of time and a continuous temporal reference. The reference used is International Atomic Time (TAI), a time scale calculated at the BIPM using data from some four hundred atomic clocks in over eighty national laboratories.
In that context, what is a "time scale"? Does it assign an hour/minute/second value to each second?
It then says
TAI is a uniform and stable scale which does not, therefore, keep in step with the slightly irregular rotation of the Earth. For public and practical purposes it is necessary to have a scale that, in the long term, does. Such a scale is Coordinated Universal Time (UTC), which is identical with TAI except that from time to time a leap second is added to ensure that, when averaged over a year, the Sun crosses the Greenwich meridian at noon UTC to within 0.9 s.
so UTC is also a "time scale". ITU-R Recommendation TF.460-6:
http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pd...
says
A positive leap-second begins at 23h 59m 60s ...
which suggests that *something* is assigning hour/minute/second values to seconds.
It also says
A positive or negative leap-second should be the last second of a UTC month ...
suggesting that the clock is tied to a calendar in some fashion.
Notice in Rec 460 it says: B International atomic time (TAI) .... It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 ..... From the Rec 460 perspective, TAI is a timescale delineated in YMDhms form, not as an uninterrupted count of seconds since 1958, as it is often treated as and referred to. UTC is also in YMDhms form, and the UTC-TAI value (10 initial offset + leap-seconds) is the difference between the two YMDhms forms. It is not a difference from between some two uninterrupted count of seconds. UTC exists only as YMDhms. This distinction between timescales represented as an uninterrupted numbered count and YMDhms labels is not always made clear. Rec 460 is stating that the alignment point between TAI and UTC in YMDhms form includes an initial 10 second offset and can be expressed as: 1972-01-01 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) Note however, as Steve Allen points out, the term, or initialization, "UTC" was not generally adopted until 1974.
On Thu 2020-11-12T18:04:08-0500 Brooks Harris hath writ:
Notice in Rec 460 it says:
B International atomic time (TAI) .... It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 .....
In documents submitted to meetings of CCDS this nomenclature was pointed out as inadequate and misleading, but there was no agreement on a better description. The actual alignment of atomic time with universal time is possible to extract from issues of Bulletin Horaire. https://www.ucolick.org/~sla/leapsecs/taiepoch.html -- 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
On 2020-11-12 19:11, Paul Gilmartin via tz asked:
Was UTC defined in 1970, or should it pedantically be GMT for 1970 and 1971; TAI-10 thereafter?
The time scale that was later called UTC was defined by the BIH since 1961-01-01. Its relation with the time scale later called TAI is given for instance in the Annual Reports of the BIH, using names TUC and UTC, of which the relevant pages are available in [ftp://ftp2.bipm.org/pub/tai/annual-reports/bih-annual-report/] The 1971 Annual Report also gives the relation of Stepped Atomic Time with TAI. Michael Deckers.
On 2020-11-12 18:11, Guy Harris wrote:
On Nov 12, 2020, at 10:02 AM, Paul Gilmartin via tz <tz@iana.org> wrote:
In: ftp://ftp.iana.org/tz/tz-link.html I read: The tz code and data support leap seconds via an optional "right" configuration, ...
Empirically, this seems to assume time_t of TAI-10. This isn't GPS, which I understand to be TAI-19: http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_utc...
TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock.
I find a couple references to "zoneinfo/right" in Makefile and NEWS. Is there more complete documentation of "right" and its rationale elsewhere? I don't know whether it's documented anywhere, but:
"right" is intended to support converting times that are represented as seconds that have elapsed since January 1, 1970, 00:00:00 UTC - as opposed to be represented as "seconds since the Epoch", which means "seconds *except for leap seconds* that have elapsed since January 1, 1970, 00:00:00 UTC" - to year/month/day/hour/minute/second.
I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX.
gmtime() would convert such a time to UTC, with "second" possibly being > 59.
To explain my understanding of the "right" tzdb data, some context is needed. The definition of UTC states that the offset UTC - TAI is a piecewise constant function of TAI (for TAI >= 1972-01-01 + 10 s). This is similar to a tzdb Zone time scale Z, where the offset Z - UTC is also a piecewise constant function (but this time, of UTC). In this way, UTC is _defined_ (by the ITU and most recently by the CGPM) like a tzdb Zone time, except that it is based on TAI and not on UTC. For the specification of UTC, however, the values of TAI - UTC are given (for instance by the IERS and the BIPM) as a function of UTC, not of TAI; hence, _as specified_, it is TAI that really is like a tzdb Zone time scale based on UTC, the same base as for all the (non-"right") tzdb Zones. The computing interfaces for tzdb data typically allow for the conversion between datetimes of UTC and datetimes of any tzdb Zone time. The conversion from datetimes of UTC into the datetime of a tzdb Zone time for the same instant is uniquely defined by the tzdb data. The converse conversion, from a datetime of a tzdb Zone time scale to a corresponding datetime of UTC for the same instant, is not so well defined since there may be no such corresponding datetime of UTC, or there may be two such. Different tzdb interfaces give various amounts of information about such cases; the behaviour ranges from no information with an unspecified choice of values up to complete information (as eg with the function convertLocalToUtc() of the Bloomberg TimeZoneUtil library). Considering TAI (since 1972-01-01 + 10 s) as a tzdb Zone time reflects exactly what is specified by the IERS about the relationship of TAI with UTC. The conversion from a UTC datetime to a corresponding TAI datetime is uniquely defined by the IERS data; the converse conversion from TAI to UTC is not, and the computing interface should give enough information for handling (positive or negative) leap seconds in UTC as desired. As far as I understand the "right" tzdb data, they express the offsets of tzdb Zone time scales as functions of TAI - 10 s (not of UTC), and they include a Zone time scale for UTC, with the offset from TAI - 10 s again expressed as a function of TAI - 10 s. This does not reflect how the offsets from UTC are specified for TAI and all the local civil time scales (viz, as functions of UTC, and not of TAI), it requires extensions in the computing interface for tzdb data, it may give wrong conversions from UTC to TAI - 10 s around leap seconds, and requires a complete change of _all_ the "right" tzdb data whenever a new leap second becomes known. HTH. Michael Deckers.
On Nov 13, 2020, at 5:17 AM, Michael H Deckers <michael.h.deckers@googlemail.com> wrote:
To explain my understanding of the "right" tzdb data, some context is needed.
The definition of UTC states that the offset UTC - TAI is a piecewise constant function of TAI (for TAI >= 1972-01-01 + 10 s).
As I understand it, in that statement, neither TAI nor UTC are expressed as a count of seconds since some epoch, with the delta being between those two counts. It means, for example, that: January 1, 1972, 00:00:00 UTC is January 1, 1972, 00:00:10 TAI; January 1, 1972, 00:00:01 UTC is January 1, 1972, 00:00:11 TAI; ... June 30, 1972, 23:59:59 UTC is July 1, 1972, 00:00:09 TAI; June 30, 1972, 23:59:60 UTC is July 1, 1972, 00:00:10 TAI; (the June 30, 1972 leap second) July 1, 1972, 00:00:00 UTC is July 1, 1972, 00:00:11 TAI (following the June 30, 1972 leap second); July 1, 1972, 00:00:01 UTC is July 1, 1972, 00:00:11 TAI; ... December 31, 1972, 23:59:59 UTC is January 1, 1973, 00:00:10 TAI; December 31, 1972, 23:59:60 UTC is January 1, 1973, 00:00:11 TAI; January 1, 1973, 00:00:00 UTC is January 1, 1973, 00:00:12 TAI (following the December 31, 1972 leap second); and so on.
The computing interfaces for tzdb data typically allow for the conversion between datetimes of UTC and datetimes of any tzdb Zone time.
The computing interfaces, with the "posix" values, allow for the conversion of a value expressed as POSIX "seconds since the Epoch" - i.e., as a count of seconds, *excluding* leap seconds, that have elapsed since the Epoch - to a date and time, expressed as year/month/day/hour/minute/second, either as UTC (gmtime()) or as local time in any tzdb region (localtime()).
The converse conversion, from a datetime of a tzdb Zone time scale to a corresponding datetime of UTC for the same instant,
Or, rather, the conversion of a date and time, expressed as year/month/day/hour/minute/second, as local time, to a value expressed as POSIX "seconds since the Epoch" (mktime()).
is not so well defined since there may be no such corresponding datetime of UTC, or there may be two such.
Yes, but that has to do with daylight saving time/summer time, *not* leap seconds.
As far as I understand the "right" tzdb data, they express the offsets of tzdb Zone time scales as functions of TAI - 10 s (not of UTC),
The tzdb data are used for converting between a time scale that uses integers (counts of seconds, whether they include or exclude leap seconds, since the Epoch) and a time scale that uses year/month/day/hour/minute/second, either as local time (localtime() to convert from the former to the latter; mktime() to convert from the latter to the former) or as UTC (gmtime() to convert from the former to the latter; the optional timegm() to convert from the latter to the former). When the tzdb code uses the "posix" data, it converts between a time scale that represents instants of time as a count of seconds, *not* including leap seconds, since the Epoch, and time scales that represent instants of time as year/month/day/hour/minute/second, either UTC or local time. When the tzdb code uses the "right" data, it converts between a time scale that represents instants of time as a count of seconds, *including* leap seconds, since the Epoch, and time scales that represent instants of time as year/month/day/hour/minute/second, either UTC or local time. The Epoch is the same in both cases. This conversion process requires knowledge of: the offset from UTC of local time for the time being converted, if the year/month/day/hour/minute/second value is in local time, but not if the year/month/day/hour/minute/second value is in UTC; the leap seconds inserted up to that time, if the count of seconds includes leap seconds, button if the count of seconds doesn't include leap seconds. The "posix" tzdb data includes data to determine the former, but not data to determine the latter; the lack of the data to determine the latter, and the expression of transition times in the data to determine the former as counts of seconds *not* including leap seconds, causes the conversion to treat counts of seconds as not including leap seconds. The "right" tzdb data includes data to determine the former, as well as data to determine the latter; the presence of the data to determine the latter, and the expression of transition times in the data to determine the former as counts of seconds *including* leap seconds, causes the conversion to treat counts of seconds as not including leap seconds. Think in those terms, and it makes more sense. Do not think of the input to gmtime() and localtime(), or the output of mktime(), as being "UTC" or as being "TAI - 10", think of it as being either "a count of seconds, other than leap seconds, since the Epoch" or "a count of seconds, including leap seconds, since the Epoch", the Epoch being the same in both cases.
On 11/13/20 2:51 PM, Guy Harris wrote:
Do not think of the input to gmtime() and localtime(), or the output of mktime(), as being "UTC" or as being "TAI - 10", think of it as being either "a count of seconds, other than leap seconds, since the Epoch" or "a count of seconds, including leap seconds, since the Epoch", the Epoch being the same in both cases.
This all sounds like good advice. The tricky part that I can see here, is that if you're using the "right" approach (where time_t is theoretically supposed to count TAI seconds), then timestamps before 1972 are all treated as if TAI−UTC equaled 10, which is not correct (for a reasonable definition of "correct"). For example, when time_t is 0 the "right" approach as implemented will report 1970-01-01 00:00:00.000000, even though a clock that consistently ticked TAI seconds should report a slightly different time. For the period from 1968-02-01 until 1972-01-01 I think the equation is: TAI−UTC = 4.2131700 s + (MJD − 39126) × 0.002592 s where JD is the Julian Date and MJD = JD − 2400000.5. The MJD for 1970-01-01 is 40587, which means that TAI−UTC was 8.000082 (not 10) at the POSIX epoch, which means for time_t 0 the "right" approach arguably should report 1970-01-01 00:00:01.999918. That's not the way "right" is implemented, of course. In "right", time_t values count TAI seconds starting in 1972, and UTC seconds before 1972. (So the name "right" is a bit of a misnomer....) I don't know of any operating system that supports TAI seconds "correctly" back to the dawn of TAI (however one wants to define when that dawn occurred). It would hardly be worth the trouble, I'd think. It may well make sense, though, for some astronomical applications to do the conversion "correctly", when interpreting historical astronomical data.
On Nov 13, 2020, at 3:51 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 11/13/20 2:51 PM, Guy Harris wrote:
Do not think of the input to gmtime() and localtime(), or the output of mktime(), as being "UTC" or as being "TAI - 10", think of it as being either "a count of seconds, other than leap seconds, since the Epoch" or "a count of seconds, including leap seconds, since the Epoch", the Epoch being the same in both cases.
This all sounds like good advice.
The tricky part that I can see here, is that if you're using the "right" approach (where time_t is theoretically supposed to count TAI seconds), then timestamps before 1972 are all treated as if TAI−UTC equaled 10, which is not correct (for a reasonable definition of "correct"). For example, when time_t is 0 the "right" approach as implemented will report 1970-01-01 00:00:00.000000, even though a clock that consistently ticked TAI seconds should report a slightly different time.
For the period from 1968-02-01 until 1972-01-01 I think the equation is:
TAI−UTC = 4.2131700 s + (MJD − 39126) × 0.002592 s
where JD is the Julian Date and MJD = JD − 2400000.5. The MJD for 1970-01-01 is 40587, which means that TAI−UTC was 8.000082 (not 10) at the POSIX epoch, which means for time_t 0 the "right" approach arguably should report 1970-01-01 00:00:01.999918.
So what documents indicate how UTC was implemented prior to 1972-01-01 00:00:00 UTC? And what documents discuss the changeover to "new" UTC (decision made in 1970 to start "new UTC' in 1972?)? And, for anybody who cares in that much detail about the definition of the Epoch, should 1970-01-01 00:00:00 UTC be interpreted as *literally* being 1970-01-01 00:00:00 UTC, or as 1970-01-01 00:00:00 "new UTC extended backwards", i.e. "TAI, and new UTC extended backwards, were 10 seconds apart from the beginning of TAI all the way up to 1972-06-30 23:59:59, and then new UTC started getting leap seconded"?
On Fri 2020-11-13T16:43:14-0800 Guy Harris hath writ:
So what documents indicate how UTC was implemented prior to 1972-01-01 00:00:00 UTC?
The source documents for the practice are the publications of the Bureau International de l'Heure, namely Bulletin Horaire through 1966 and Circular D after that. See the index of issues https://www.ucolick.org/~sla/leapsecs/bhissues.html Within those issues are references to the international agreements which BIH was tasked to implement, and a lot more nitty gritty. detail than is found in wikipedia or any summary.
And what documents discuss the changeover to "new" UTC (decision made in 1970 to start "new UTC' in 1972?)?
The source documents are from the BIH, CCDS, CIPM, CGPM, IAU, URSI, CCIR, IEEE, etc., and also memoirs of the dramatis personae at those meetings. Again, no summary tries to capture the whole story, and it is evident that details were redacted from the public proceedings.
And, for anybody who cares in that much detail about the definition of the Epoch, should 1970-01-01 00:00:00 UTC be interpreted as *literally* being 1970-01-01 00:00:00 UTC, or as 1970-01-01 00:00:00 "new UTC extended backwards", i.e. "TAI, and new UTC extended backwards, were 10 seconds apart from the beginning of TAI all the way up to 1972-06-30 23:59:59, and then new UTC started getting leap seconded"?
If you ask me for the value of arcsin(-2) I can give you a value, but the utility of that value requires understanding complex analysis. The answer depends on the needs of the application. -- 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
Guy Harris <gharris@sonic.net> wrote:
So what documents indicate how UTC was implemented prior to 1972-01-01 00:00:00 UTC?
One example is the USNO TAI-UTC file which includes details of their version of 1960s rubber second UTC. The server is currently unavailable (undergoing modernization, they say) but you can find copies via http://web.archive.org/web/*/http://maia.usno.navy.mil/ser7/tai-utc.dat I don't know which other timekeeping agencies used the same formulae. (NIST? RGO? NPL?)
And, for anybody who cares in that much detail about the definition of the Epoch, should 1970-01-01 00:00:00 UTC be interpreted as *literally* being 1970-01-01 00:00:00 UTC, or as 1970-01-01 00:00:00 "new UTC extended backwards",
Neither :-) POSIX (as you know) disclaims any relationship between struct tm values and actual time of day, so the meaning of timestamps in that range, or any other range for that matter, is "whatever flavour of UTC or GMT or zulu time makes the most sense and is most convenient". Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Fair Isle: Southwest 6 to gale 8, becoming cyclonic 4 to 6. Rough or very rough, becoming moderate or rough. Rain or showers. Good, occasionally poor.
On 2020-11-16 22:48, Tony Finch asked about UTC:
I don't know which other timekeeping agencies used the same formulae. (NIST? RGO? NPL?)
UTC was defined by the BIH since 1961 as a function of TAI. See eg the excerpts of the Annual Reports by the BIH available at [https://www.bipm.org/en/bipm-services/timescales/time-ftp/annual-reports.htm...] These excerpts also contain a list of time signals following UTC (or SAT) as defined by the BIH. Michael Deckers.
On Tue 2020-11-17T13:23:36+0000 Michael H Deckers via tz hath writ:
UTC was defined by the BIH since 1961 as a function of TAI.
Alas the process was not that simple, and the issues of BIH Bulletin Horaire have the tabulations that show how messy it was. One of the UK radio time signals had begun to be based on the Greenwich atomic time scale in the late 1950s. The US NBS had a similar scheme for WWV based on the NBS atomic chronometers, and the USNO time signals used their own scheme which was more directly connected to astronomical observations of recent years. US NBS gave a smoother time scale and USNO gave a time scale closer to astronomical time needed for navigation. Folks running those schemes got the 9th CCIR plenary assembly in 1959 April to recommend that all time signals should be based on cesium chronometers. In August H.M. Smith of UK had folks from the US for afternoon tea at his house and they agreed to use the same frequency offsets and steps. This was "coordination". Early in 1960 USNO and one of the UK time signal stations were using the same scheme. In April both of the main UK time signal stations started using that same scheme. In May the UK and US met to make a formal agreement about the coordination scheme. "Full coordination" between the US and UK time signals was achieved 1961-01-01. In 1961 April the CCDS saw that various sites with cesium chronometers had begun to construct atomic time scales. They recommended that BIH should use its equipment and skill to compute an atomic time scale as BIH had always been doing with astronomical time. By October Anna Stoyko had created tabulations of atomic time scales beginning on 1961-01-01. In 1961 August the 11th IAU General Assembly learned that radio time signals agreed at the unprecedented level of 1 ms, and with their oversight of the BIH they recommended that BIH should compute the frequency offsets and steps starting for 1962. The Stoykos retired from BIH in 1965, Guinot became head of service. For 1964 Guinot had begun to change the BIH tabulations that had been in use since the 1920s. The original tabulations had regarded the time at observatories as the reference. The new tabulations regarded the time of the broadcast time signals as the reference. Guinot began tabulating "UTC" for the year 1964. Those issues of Bulletin Horaire were not published until 1965, but they are the first appearance of the term "UTC" (actually TUC) anywhere. For 1964 "UTC" was as all previous BIH tabulations; it was determined by combining/averaging the received radio broadcast signals of all stations claiming to be emitting coordinated time. It was not based on the BIH time scale. For 1965 Guinot determined the frequency offset and steps for coordinated time, and starting with 1965 UTC(BIH) was computed as a function of the BIH atomic time scale. Starting 1965 old UTC begins to be based on what would become TAI. It was not until 1968 that the US NBS and the USNO decided to bring their broadcasts of coordinated time into sync at the microsecond level. Up until 1972-01-01 the Soviet radio broadcast time signals were using their own values of frequency offset and steps which were not the same as BIH values for coordinated time. During most of this interval the US NBS was broadcasting old UTC (never using that name) and stepped atomic time on two different stations. Old UTC had been deemed illegal in Germany by a law passed in 1969 July, but the German DCF77 continued broadcasting old UTC at some hours of the day until 1970 April. -- 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
On 2020-11-17 16:21, Steve Allen wrote:
On Tue 2020-11-17T13:23:36+0000 Michael H Deckers via tz hath writ:
UTC was defined by the BIH since 1961 as a function of TAI. Alas the process was not that simple, and the issues of BIH Bulletin Horaire have the tabulations that show how messy it was.
Thanks for the details! Yes, it must have been quite complex -- the BIH has established a reference time scale (later called UTC) to which the most accurate time signals could be traced to microsecond precision, and to which the less accurate determinations of UT1 could be related, while the methods of precise time and frequency transfer have been rapidly evolving. Michael Deckers.
On Fri 2020-11-13T15:51:49-0800 Paul Eggert hath writ:
It would hardly be worth the trouble, I'd think. It may well make sense, though, for some astronomical applications to do the conversion "correctly", when interpreting historical astronomical data.
For the past 25 years the range residuals to Mars fall inside an envelope 2 meters big. Similarly tight ranges apply for every other planet that has had an orbiter or lander. Trying to construct an epemeris by adding in older observations does not improve the result, it only adds noise. Not even for astronomical purposes is the exact nature of the time around 1970/1972 relevant. -- 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
On 2020-11-14 02:29, Steve Allen wrote:
Not even for astronomical purposes is the exact nature of the time around 1970/1972 relevant.
Except, of course, for several precisely timed observations of Mars and the outer planets since 1911 used in the DE 405 ephemeris. Michael Deckers.
On 11/13/20 6:29 PM, Steve Allen wrote:
On Fri 2020-11-13T15:51:49-0800 Paul Eggert hath writ:
It may well make sense, though, for some astronomical applications to do the conversion "correctly", when interpreting historical astronomical data.
For the past 25 years the range residuals to Mars fall inside an envelope 2 meters big. Similarly tight ranges apply for every other planet that has had an orbiter or lander. Trying to construct an epemeris by adding in older observations does not improve the result, it only adds noise.
All true. I was thinking of more of historical astronomy, something like "How accurately were astronomers taking measurements in the 1970s?". PS. To be honest I was also thinking of less-navelgazing questions, such as "Has the gravitational constant changed in the last century or two, and can we tell this by looking at old records?" but now that I've looked into that particular question I was blowing smoke. Recent research on possible variations in the gravitational constant have been more along the lines of constraints from Big Bang nucleosynthesis or from asteroseismic measurements, and circa-1970 astronomical records are useless for that.
On Nov 13, 2020, at 2:51 PM, Guy Harris <gharris@sonic.net> wrote:
On Nov 13, 2020, at 5:17 AM, Michael H Deckers <michael.h.deckers@googlemail.com> wrote:
The computing interfaces for tzdb data typically allow for the conversion between datetimes of UTC and datetimes of any tzdb Zone time.
The computing interfaces, with the "posix" values, allow for the conversion of a value expressed as POSIX "seconds since the Epoch" - i.e., as a count of seconds, *excluding* leap seconds, that have elapsed since the Epoch - to a date and time, expressed as year/month/day/hour/minute/second, either as UTC (gmtime()) or as local time in any tzdb region (localtime()).
If you want to convert between year/month/day/hour/minute/second as UTC and year/month/day/hour/minute/second as local time, do: struct tm * utc_to_local(struct tm *utc) { time_t tmp; tmp = {do the calculation based on the values in *utc}; return localtime(&tmp); } to go from UTC to local time and struct tm * local_to_utc(struct tm *local) { time_t tmp; tmp = mktime(local); if (tmp == -1) return NULL; /* no can do */ return gmtime(&tmp); } to go from local time to UTC. Note that these will work correctly for UTC times with second = 60 - i.e., for leap seconds - only if 1) you are using the "right" tzdb files and 2) {do the calculation based on the values in *utc} involves using timegm(), if available, using the leap second information from the "right" tzdb files. Otherwise, Weird Stuff may happen if you try to convert, for example, 2016-12-31 23:59:60 UTC to local time. It *also* requires that For example, on Ubuntu 20.04, which has the "right" values, the following program: /* * Yes, I want all the APIs. */ #define _DEFAULT_SOURCE #define _XOPEN_SOURCE #include <stdio.h> #include <time.h> static struct tm * utc_to_local(struct tm *utc) { time_t tmp; tmp = timegm(utc); return localtime(&tmp); } static struct tm * local_to_utc(struct tm *local) { time_t tmp; tmp = mktime(local); if (tmp == -1) return NULL; /* no can do */ return gmtime(&tmp); } int main(int argc, char **argv) { struct tm input; struct tm *output; char bufin[1024+1], bufout[1024+1]; if (argc != 2) { fprintf(stderr, "Usage: timetest <time>\n"); return 1; } if (strptime(argv[1], "%Y-%m-%d %H:%M:%S", &input) == NULL) { fprintf(stderr, "timetest: \"%s\" is not a valid time\n", argv[1]); return 2; } input.tm_isdst = -1; strftime(bufin, sizeof bufin, "%Y-%m-%d %H:%M:%S", &input); printf("%s is converted to %04d-%02d-%02d %02d:%02d:%02d\n", argv[1], input.tm_year + 1900, input.tm_mon + 1, input.tm_mday, input.tm_hour, input.tm_min, input.tm_sec); output = utc_to_local(&input); strftime(bufin, sizeof bufin, "%Y-%m-%d %H:%M:%S", &input); strftime(bufout, sizeof bufout, "%Y-%m-%d %H:%M:%S", output); printf("%s in UTC is %s in local time\n", bufin, bufout); if (strptime(argv[1], "%Y-%m-%d %H:%M:%S", &input) == NULL) { fprintf(stderr, "timetest: \"%s\" is not a valid time\n", argv[1]); return 2; } input.tm_isdst = -1; strftime(bufin, sizeof bufin, "%Y-%m-%d %H:%M:%S", &input); printf("%s is converted to %04d-%02d-%02d %02d:%02d:%02d\n", argv[1], input.tm_year + 1900, input.tm_mon + 1, input.tm_mday, input.tm_hour, input.tm_min, input.tm_sec); output = local_to_utc(&input); strftime(bufin, sizeof bufin, "%Y-%m-%d %H:%M:%S", &input); strftime(bufout, sizeof bufout, "%Y-%m-%d %H:%M:%S", output); printf("%s in local time is %s in UTC\n", bufin, bufout); return 0; } produces the following output with the "posix" files, in my time zone: $ ./timetest "2016-12-31 23:59:60" 2016-12-31 23:59:60 is converted to 2016-12-31 23:59:60 2017-01-01 00:00:00 in UTC is 2016-12-31 16:00:00 in local time 2016-12-31 23:59:60 is converted to 2016-12-31 23:59:60 2017-01-01 00:00:00 in local time is 2017-01-01 08:00:00 in UTC and the following output with the "right" files, in my time zone: $ TZ=right/America/Los_Angeles ./timetest "2016-12-31 23:59:60" 2016-12-31 23:59:60 is converted to 2016-12-31 23:59:60 2016-12-31 23:59:60 in UTC is 2016-12-31 15:59:60 in local time 2016-12-31 23:59:60 is converted to 2016-12-31 23:59:60 2017-01-01 00:00:00 in local time is 2017-01-01 08:00:00 in UTC Note that either gmtime() and localtime(), if the "posix" files are being used, will "fix" the members of the input struct tm, but will *not* do so if the "right" files are being used.
On 2020-11-14 00:20, Guy Harris wrote:
On Nov 13, 2020, at 5:17 AM, Michael H Deckers <michael.h.deckers@googlemail.com> wrote:
The computing interfaces for tzdb data typically allow for the conversion between datetimes of UTC and datetimes of any tzdb Zone time. The computing interfaces, with the "posix" values, allow for the conversion of a value expressed as POSIX "seconds since the Epoch" - i.e., as a count of seconds, *excluding* leap seconds, that have elapsed since the Epoch - to a date and time, expressed as year/month/day/hour/minute/second, either as UTC (gmtime()) or as local time in any tzdb region (localtime()). If you want to convert between......
Thanks for all the details! Actually, localtime_rz() and mktime_z() should suffice, and for the "right" tzdb data, posix2time() and time2posix(). Actually, I meant the modern interfaces as in Java etc where the change of representation (choice of calendar, MJD, POSIX count of seconds since 1970, etc) is separated from the conversion among time scales (UTC, tzdb Zone time scale values, and perhaps other time scales), and where the conversions supply enough additional information if the conversion is not bijective. The C library interface is not sufficient (at least not without quite a bit of additional work) to convert the UTC value 2016-12-31T23:59:60.5 into the value 2016-12-31T15:59:60.5-08:00 of Pacific time. Michael Deckers.
On Sat, 2020-11-14 at 21:48 +0000, Michael H Deckers via tz wrote:
The C library interface is not sufficient (at least not without quite a bit of additional work) to convert the UTC value 2016-12-31T23:59:60.5 into the value 2016-12-31T15:59:60.5-08:00 of Pacific time.
Michael Deckers.
That is correct, and I have done the work. It is available as a tarball at https://github.com/ShowControl/libtime and in COPR at johnsauter/libtime. You can download the documentation from this URL: https://commons.wikimedia.org/wiki/File:Avoid_Using_POSIX_time_t_for_Telling... John Sauter (John_Sauter@systemeyescomputerstore.com) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
On 2020-11-13 22:51, Guy Harris wrote:
On Nov 13, 2020, at 5:17 AM, Michael H Deckers <michael.h.deckers@googlemail.com> wrote:
The definition of UTC states that the offset UTC - TAI is a piecewise constant function of TAI (for TAI >= 1972-01-01 + 10 s).
As I understand it, in that statement, neither TAI nor UTC are expressed as a count of seconds since some epoch, with the delta being between those two counts.
The definition of a time scale, and the difference of two time scales, is independent of the units used to express values of time or of a time scale. Values of every time scale can be expressed as seconds since some arbitrarily chosen epoch, such as Julian date (as days since the Gregorian date -4713-11-25 + 12 h), as MJD or as a date expressed in some calendar date plus a time of day expressed in one or more time units. It's like a temperature that does not change when you express it in °C or °F instead of K.
the delta being between those two counts. It means, for example, that:... June 30, 1972, 23:59:60 UTC is July 1, 1972, 00:00:10 TAI; (the June 30, 1972 leap second)
The notation "1972-06-30T23:59:60" for a UTC value is a shorthand for: "the UTC value at the instant when TAI is 1972-07-01T00:00:10". That UTC value obviously would be 1972-07-01T00:00:00 if TAI - UTC were 10 s at that instant; and it would be 1972-06-30T23:59:59 if TAI - UTC were 11 s at that instant; the IERS just does not specify which value of TAI - UTC applies at that instant.
The computing interfaces, with the "posix" values, allow for the conversion of a value expressed as POSIX "seconds since the Epoch" - i.e., as a count of seconds, *excluding* leap seconds, that have elapsed since the Epoch - to a date and time, expressed as year/month/day/hour/minute/second, either as UTC (gmtime()) or as local time in any tzdb region (localtime()).
I prefer to say "TAI - X expressed in seconds" and "UTC - X expressed in seconds" because the recipe for not counting a negative leap second in the "count of seconds except leap seconds since X" is quite misleading.
The converse conversion, from a datetime of a tzdb Zone time scale to a corresponding datetime of UTC for the same instant,
is not so well defined since there may be no such corresponding datetime of UTC, or there may be two such.
Yes, but that has to do with daylight saving time/summer time, *not* leap seconds.
This year, at the instant when UTC was 2020-03-08T10Z, Pacific time jumped from 2010-03-08T02 to 2010-03-08T03, and when UTC was 2017-01-01T00Z, TAI jumped from 2017-01-01T00:00:36 to 2017-01-01T00:00:37, as the IERS tells us. Since the rates of UTC, Pacific time and TAI are the same, the question, what was UTC when Pacific time was 2010-03-08T02:30, is exactly similar to the question what was UTC when TAI was 2017-01-01T00:00:36.5. Michael Deckers.
On Sat, 2020-11-14 at 20:23 +0000, Michael H Deckers via tz wrote:
This year, at the instant when UTC was 2020-03-08T10Z, Pacific time jumped from 2010-03-08T02 to 2010-03-08T03, and when UTC was 2017-01-01T00Z, TAI jumped from 2017-01-01T00:00:36 to 2017-01-01T00:00:37, as the IERS tells us. Since the rates of UTC, Pacific time and TAI are the same, the question, what was UTC when Pacific time was 2010-03-08T02:30, is exactly similar to the question what was UTC when TAI was 2017-01-01T00:00:36.5.
Michael Deckers.
Since 2017-01-01T00:00:36.5 TAI is a valid time, and UTC has a name for every second, there must be a corresponding UTC time. If I have done my arithmetic correctly, that time is 2016-12-31T23:59:60.5 UTC. This is not the same as asking for the UTC corresponding to 2010-03- 08T02:30 Pacific time, because that is not a valid time. That is, there is no point in time with that name. John Sauter (John_Sauter@systemeyescomputerstore.com) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
On 2020-11-14 20:48, John Sauter wrote:
On Sat, 2020-11-14 at 20:23 +0000, Michael H Deckers via tz wrote:
This year, at the instant when UTC was 2020-03-08T10Z, Pacific time jumped from 2010-03-08T02 to 2010-03-08T03, and when UTC was 2017-01-01T00Z, TAI jumped from 2017-01-01T00:00:36 to 2017-01-01T00:00:37, as the IERS tells us. Since the rates of UTC, Pacific time and TAI are the same, the question, what was UTC when Pacific time was 2010-03-08T02:30, is exactly similar to the question what was UTC when TAI was 2017-01-01T00:00:36.5.
Michael Deckers.
Since 2017-01-01T00:00:36.5 TAI is a valid time, and UTC has a name for every second, there must be a corresponding UTC time. If I have done my arithmetic correctly, that time is 2016-12-31T23:59:60.5 UTC.
This is not the same as asking for the UTC corresponding to 2010-03- 08T02:30 Pacific time, because that is not a valid time. That is, there is no point in time with that name. John Sauter (John_Sauter@systemeyescomputerstore.com)
Neither the function that maps UTC to Pacific time nor the function defined by the IERS that maps UTC to a corresponding value of TAI are surjective, and the interface has to tell that. In that sense, the cases are similar. The leap second notation is only applicable with notations with enough redundancy, it is not the only possible notation indicating a leaps in UTC, and it does not work for UTC <= 1972. Nor does it help if the user wants to determine TAI - UTC for a given value of TAI. Another notation for leaps in UTC was recommended by the IAU in 1970: 9.4. The time of an event given in the old scale, before the leap second, will be given as a date in the previous month, exceeding 24h if necessary. The time of an event given in the scale after the step will be given as a date in the new month, with a negative time, if necessary. Resolution adopted by the 14th General Assembly of the IAU in 1970, online at [https://www.cambridge.org/core/services/aop-cambridge-core/content /view/FEF0CB0CE755B4F67813AEC1E3596DEF/S0251107X0002023Xa.pdf/commission_31_time.pdf] Michael Deckers.
On Sun, 2020-11-15 at 10:51 +0000, Michael H Deckers wrote:
Neither the function that maps UTC to Pacific time nor the function defined by the IERS that maps UTC to a corresponding value of TAI are surjective, and the interface has to tell that. In that sense, the cases are similar.
I had to look up "surjective"; I thought at first it was a typo for "subjective". If I am understanding that word correctly, I think I must be defining the domains of Pacific Time, UTC and TAI differently than you do. I regard those domains as containing only labels for instants of time. Thus, 2018-03-08T02:30 is not a member of the Pacific Time domain since it does not label an instant of time. By my definition, every Pacific Time label corresponds to a UTC label, and all UTC labels have a corresponding Pacific Time label, and thus the mapping is surjective. Similarly, every second has both a UTC label and a TAI label, so the function that maps UTC to TAI is surjective. To take an extreme example for purposes of illustration, the label 2020-11-15T99:99:99Z is not a member of the UTC domain, since there is no second with this label, so converting it to Pacific Time or TAI does not make sense.
The leap second notation is only applicable with notations with enough redundancy, it is not the only possible notation indicating a leaps in UTC, and it does not work for UTC <= 1972. Nor does it help if the user wants to determine TAI - UTC for a given value of TAI.
I regard TAI and UTC as collections of labels rather than numbers, so TAI - UTC is not meaningful unless you convert both to numbers. The result of the subtraction will depend on how you map the labels onto numbers.
Another notation for leaps in UTC was recommended by the IAU in 1970: 9.4. The time of an event given in the old scale, before the leap second, will be given as a date in the previous month, exceeding 24h if necessary. The time of an event given in the scale after the step will be given as a date in the new month, with a negative time, if necessary. Resolution adopted by the 14th General Assembly of the IAU in 1970, online at [https://www.cambridge.org/core/services/aop-cambridge-core/content/view/FEF0...]
So the alternative notation for 2016-12-31T23:59:60Z would be 2016-12- 31T24:00:00Z. That looks strange to modern eyes, but I don't think it is any worse than extending the minute. Other possibilities are to extend the hour: 2016-21-31T23:60:00Z, the month: 2016-12-32T00:00:00Z, or the year: 2016-13-01T00:00:00Z. John Sauter (John_Sauter@systemeyescomputerstore.com) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
On 2020-11-15 14:46, John Sauter wrote:
On Sun, 2020-11-15 at 10:51 +0000, Michael H Deckers wrote:
Neither the function that maps UTC to Pacific time nor the function defined by the IERS that maps UTC to a corresponding value of TAI are surjective, and the interface has to tell that. In that sense, the cases are similar.
I had to look up "surjective"; I thought at first it was a typo for "subjective". ..........
I am sorry; I should at least have included a warning that this is mathematical lingo.
........ If I am understanding that word correctly, I think I must be defining the domains of Pacific Time, UTC and TAI differently than you do. I regard those domains as containing only labels for instants of time. Thus, 2018-03-08T02:30 is not a member of the Pacific Time domain since it does not label an instant of time. By my gdefinition, every Pacific Time label corresponds to a UTC label, and all UTC labels have a corresponding Pacific Time label, and thus the mapping is surjective.
Similarly, every second has both a UTC label and a TAI label, so the function that maps UTC to TAI is surjective.
To take an extreme example for purposes of illustration, the label 2020-11-15T99:99:99Z is not a member of the UTC domain, since there is no second with this label, so converting it to Pacific Time or TAI does not make sense.
The leap second notation is only applicable with notations with enough redundancy, it is not the only possible notation indicating a leaps in UTC, and it does not work for UTC <= 1972. Nor does it help if the user wants to determine TAI - UTC for a given value of TAI. I regard TAI and UTC as collections of labels rather than numbers, so TAI - UTC is not meaningful unless you convert both to numbers. The result of the subtraction will depend on how you map the labels onto numbers.
I think the view that different time scales are just relabelings of the point of a time line is fundamentally flawed. I consider a time scale to be the temporal part of a coordinate system for 4-dimensional spacetime; changing the coordinate system, even if it is only for one coordinate, does not mean relabeling the coordinate. Yes, there are many people and several authors which understand the term, time scale, in other meanings (eg, ISO 8601). And a geological time scale is probably not (yet?) part of a coordinate system. At any rate, the values of (such) time scales are points on the time line, which offers the well known operations (adding a time value to a time point, determining the difference between two time points, etc). These are operations on physical quantities, and cannot be done with labels. Different time scales must take their values on the same time line (at least when their values are to be comparable). Points on the time line can be denoted in many different ways: with many calendars, many time units for time of day and time since an epoch, and many different epochs for such counts; changing a notation does not change the time scale anymore than an elevation is changed by switching its notation from foot to meter. When it is said that UTC is just TAI with the points on the time line relabeled, this just means that the function from TAI values to UTC values ("labels") is injective (ie, different values of TAI are mapped to different labels). This is correct for a suitable choice of leap second notations -- but it does not tell us much about how UTC depends on TAI. In the the same way, one could say that x³ is just a relabeling of x, but this does not tell us how x³ depends on x, it doesn't allow comparison of x³ with x, taking the derivative etc.
Another notation for leaps in UTC was recommended by the IAU in 1970: 9.4. The time of an event given in the old scale, before the leap second, will be given as a date in the previous month, exceeding 24h if necessary. The time of an event given in the scale after the step will be given as a date in the new month, with a negative time, if necessary. Resolution adopted by the 14th General Assembly of the IAU in 1970, online at [https://www.cambridge.org/core/services/aop-cambridge-core/content/view/FEF0...] So the alternative notation for 2016-12-31T23:59:60Z would be 2016-12- 31T24:00:00Z. No, the IAU mean 2017-01-01 - 01 s, a negative value for time of day.
Michael Deckers.
On Sun 2020-11-15T22:31:01+0000 Michael H Deckers via tz hath writ:
� No, the IAU mean 2017-01-01 - 01 s, a negative value � for time of day.
The members of IAU Comm 31 almost certainly did not mean for the time to have a negative value. In astronomical almanacs and tabulations it is extremly common to find date notations like January 0 and October 35. These notations allowed tabulations of an entire month to be greatly compacted way back in an age where every table was typeset by hand and often strained the margins trying to include all the numbers. (As an aside, anybody who eventually wants machines to parse OCR scans of volumes with such tables is going to have to find (or construct) a date parser which does not throw errors when it encounters such date notation.) So for the above case the timestamp would be 2017-01-00T23:59:59 where by being in 2017 January it is understood that this time notation applies to the scale that is continuous after the leap. -- 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
On 2020-11-15 23:20, Steve Allen wrote:
The members of IAU Comm 31 almost certainly did not mean for the time to have a negative value.
Commission 31 is quite explicit: 9.4. ..The time of an event given in the scale after the step will be given as a date in the new month, with a negative time, if necessary. (Of course, I got that from your site, thanks.) Michael Deckers.
On Sun 2020-11-15T23:28:29+0000 Michael H Deckers hath writ:
Commission 31 is quite explicit:
The proofreading of these minutes was distracted by serious issues. https://www.cambridge.org/core/services/aop-cambridge-core/content/view/FEF0... On page 198 point 9.2 definitely has a typo. This is not surprising given that the minutes of the first session on August 19 have had at least one paragraph redacted lest the IAU proceedings reveal the level of disagreement about leap seconds among the very same people who had been part of the meetings leading to that decision. Winkler, president at that meeting, was co-author (with Sadler) of one of the reports contributed before the 1970 IAU GA which said that leap seconds would cause failures in air traffic collision avoidance systems, and he later published USNO bulletins which described how the USNO was not going to be using UTC for its systems. Sadler, also at that meeting, later revealed that the proceedings of the 4th CCDS meeting for which there is a record are actually the proceedings of the *second* 4th CCDS meeting. The *first* 4th CCDS meeting was stricken from all records, so the redaction of a paragraph or two at the IAU is mild by comparison. For fun here is a photo of the IAU excursion from Brighton up to London on 1970 August 23 -- after the first two contentious sessions of Comm 31, during the wordsmithing phase that led to the results in the last two sessions of Comm 31. https://www.ucolick.org/~sla/temporary/IAU19700823Sadler.jpg At the right walking toward the camera along the path is D.H. Sadler, no doubt in contemplation of the draft statement for the next day where he would ask for a vote about whether leap seconds really were the "optimum solution". -- 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
On Sun, 2020-11-15 at 22:31 +0000, Michael H Deckers wrote:
I think the view that different time scales are just relabelings of the point of a time line is fundamentally flawed. I consider a time scale to be the temporal part of a coordinate system for 4-dimensional spacetime; changing the coordinate system, even if it is only for one coordinate, does not mean relabeling the coordinate.
Yes, there are many people and several authors which understand the term, time scale, in other meanings (eg, ISO 8601). And a geological time scale is probably not (yet?) part of a coordinate system.
At any rate, the values of (such) time scales are points on the time line, which offers the well known operations (adding a time value to a time point, determining the difference between two time points, etc). These are operations on physical quantities, and cannot be done with labels. Different time scales must take their values on the same time line (at least when their values are to be comparable).
Points on the time line can be denoted in many different ways: with many calendars, many time units for time of day and time since an epoch, and many different epochs for such counts; changing a notation does not change the time scale anymore than an elevation is changed by switching its notation from foot to meter.
When it is said that UTC is just TAI with the points on the time line relabeled, this just means that the function from TAI values to UTC values ("labels") is injective (ie, different values of TAI are mapped to different labels). This is correct for a suitable choice of leap second notations -- but it does not tell us much about how UTC depends on TAI. In the the same way, one could say that x³ is just a relabeling of x, but this does not tell us how x³ depends on x, it doesn't allow comparison of x³ with x, taking the derivative etc.
I take your point: to do anything useful we need more than labels--we need to know how those labels relate to time. To some extent, we are misled by the similarity in structure between UTC labels and TAI labels into thinking that they are related more fundamentally than they actually are. Suppose we define the difference between TAI and UTC as follows: write down the current value of UTC, and measure how many seconds before TAI has that same value. That works fine except during a leap second, when we will wait in vain for a TAI time that ends in 23:59:60. I think it would be reasonable to say that TAI - UTC has no meaning during a leap second.
Another notation for leaps in UTC was recommended by the IAU in 1970: 9.4. The time of an event given in the old scale, before the leap second, will be given as a date in the previous month, exceeding 24h if necessary. The time of an event given in the scale after the step will be given as a date in the new month, with a negative time, if necessary. Resolution adopted by the 14th General Assembly of the IAU in 1970, online at [ https://www.cambridge.org/core/services/aop-cambridge-core/content/view/FEF0... ] So the alternative notation for 2016-12-31T23:59:60Z would be 2016- 12- 31T24:00:00Z. No, the IAU mean 2017-01-01 - 01 s, a negative value for time of day.
If I am reading section 9.4 correctly, they are defining two time scales: the old scale (before the leap second) and the scale after the step. In the old scale the leap second at the end of 2016 would start at 2016-12-31T24:00:00 and end at 2016-12-31:24:00:01. In the scale after the step the leap second would start at 2017-01-01:00:00:-1 and end at 2017-01-01T00:00:00. Before the leap second starts it is best to use only the old scale, and after the leap second ends the best scale to use is the scale after the step. During the leap second both scales are useful. John Sauter (John_Sauter@systemeyescomputerstore.com) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
On 2020-11-15 23:21, John Sauter wrote:
If I am reading section 9.4 correctly, they are defining two time scales: the old scale (before the leap second) and the scale after the step. In the old scale the leap second at the end of 2016 would start at 2016-12-31T24:00:00 and end at 2016-12-31:24:00:01. In the scale after the step the leap second would start at 2017-01-01:00:00:-1 and end at 2017-01-01T00:00:00.
Yes. The rationale of a positive leap second notation for a time point is to indicate that the point does not belong to the normal range of datetime values, where there are only 20 seconds from 2016-12-31T23:59:50 to 2017-01-01T00:00:10. One therefore has to use a notation that cannot be confused with notations that are used for these normal datetime values. Exceeding the normal range [0..1[ d of time of day is one method; the ITU method uses times of day >= 1 day, but times of day < 0 d could similarly be used. Other means would be affixes to the notation (such as the leap second bit in the Ada programming language, or the labels "A", "B" proposed to distinguish duplicate timestamps during fall back from summer time in Denmark and Germany). Michael Deckers.
On Mon, 2020-11-16 at 10:29 +0000, Michael H Deckers wrote:
On 2020-11-15 23:21, John Sauter wrote:
If I am reading section 9.4 correctly, they are defining two time scales: the old scale (before the leap second) and the scale after the step. In the old scale the leap second at the end of 2016 would start at 2016-12-31T24:00:00 and end at 2016-12-31:24:00:01. In the scale after the step the leap second would start at 2017-01-01:00:00:-1 and end at 2017-01-01T00:00:00.
Yes.
The rationale of a positive leap second notation for a time point is to indicate that the point does not belong to the normal range of datetime values, where there are only 20 seconds from 2016-12-31T23:59:50 to 2017-01-01T00:00:10. One therefore has to use a notation that cannot be confused with notations that are used for these normal datetime values.
Exceeding the normal range [0..1[ d of time of day is one method; the ITU method uses times of day >= 1 day, but times of day < 0 d could similarly be used. Other means would be affixes to the notation (such as the leap second bit in the Ada programming language, or the labels "A", "B" proposed to distinguish duplicate timestamps during fall back from summer time in Denmark and Germany).
Michael Deckers.
In addition, following Steve Allen's suggestion, the start of the leap second in the time scale after the step could be 2017-01-00T23:59:59. John Sauter (John_Sauter@systemeyescomputerstore.com) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
On 2020-11-16 14:15, John Sauter wrote:
In addition, following Steve Allen's suggestion, the start of the leap second in the time scale after the step could be 2017-01-00T23:59:59.
Yes, it is. But I am not aware of an official definition of what a leap second is. A positive leap second is usually taken to be a (left closed and right open) interval of length 1 s of TAI values that are not associated with UTC values by the function from UTC to TAI as published by the IERS. For the latest leap second this interval was [2017-01-01T00:00:36..2017-01-01T00:00:37[; while TAI was in that interval, UTC could be 36 s or 37 s less than TAI, and ITU recommends the use of their leap second notation for the value of UTC. Michael Deckers.
On 2020-11-16, at 11:44:07, Michael H Deckers via tz <tz@iana.org> wrote:
A positive leap second is usually taken to be a (left closed and right open) interval of length 1 s of TAI values that are not associated with UTC values by the function from UTC to TAI as published by the IERS. For the latest leap second this interval was [2017-01-01T00:00:36..2017-01-01T00:00:37[; while TAI was in that interval, UTC could be 36 s or 37 s less than TAI, and ITU recommends the use of their leap second notation for the value of UTC.
Is that the same as?: https://datacenter.iers.org/data/16/bulletinc-052.txt A positive leap second will be introduced at the end of December 2016. The sequence of dates of the UTC second markers will be: 2016 December 31, 23h 59m 59s 2016 December 31, 23h 59m 60s 2017 January 1, 0h 0m 0s The UTC "23:59:60" is extraordinary; I'd call it the "leap second". A "negative leap second" is problematic. It would be a TAI second with no matching UTC second. -- gil
On Nov 16, 2020, at 1:11 PM, Paul Gilmartin via tz <tz@iana.org> wrote:
https://datacenter.iers.org/data/16/bulletinc-052.txt
A positive leap second will be introduced at the end of December 2016. The sequence of dates of the UTC second markers will be:
2016 December 31, 23h 59m 59s 2016 December 31, 23h 59m 60s 2017 January 1, 0h 0m 0s
The UTC "23:59:60" is extraordinary; I'd call it the "leap second".
Yes, that's what it is.
A "negative leap second" is problematic. It would be a TAI second with no matching UTC second.
At least as I read ITU-R Recommendation TF.460-6: https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.p... if a second is removed, UTC goes from 23h 59m 58s to 0h 0m 0s the next day, so, if TAI second {year}-{month}-{day} {hour}:{minute}:{second} corresponds to UTC second {year'}-12-31 23:59:58, the subsequent TAI second would correspond to UTC second {year'+1}-01-01 00:00:00. Yes, there would be no UTC second {year'}-12-31 23:59:59, but that's not "no matching UTC second" as I see it.
On 2020-11-16 21:11, Paul Gilmartin wrote:
A "negative leap second" is problematic. It would be a TAI second with no matching UTC second.
No. Let us assume that a negative leap second will be "dropped" in UTC at 2028-01-01, so that for UTC directly before 2028-01-01, one has TAI - UTC = 37 s for UTC on and directly after 2028-01-01, one has TAI - UTC = 36 s. Then there are successive timestamps 2027-12-31T23:59:57 2027-12-31T23:59:58 2028-01-01T00:00:00 in UTC when TAI is one of 2028-01-01 + {34, 35, 36} s. In ITU lingo, the negative leap second is 2027-12-31T23:59:59. There is no "corresponding second of" TAI. To make matters even more confusing, consider that TAI "counts seconds" including positive leap seconds but excluding negative leap seconds, and UTC "counts seconds" excluding positive leap seconds but including negative leap seconds. Michael Deckers.
On Thu 2020-11-12T11:02:42-0700 Paul Gilmartin via tz hath writ:
Empirically, this seems to assume time_t of TAI-10. This isn't GPS, which I understand to be TAI-19: http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_utc...
TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock.
I find a couple references to "zoneinfo/right" in Makefile and NEWS. Is there more complete documentation of "right" and its rationale elsewhere?
TAI - 10 is the time scale that was adopted by USNO navigational systems (OMEGA, TRANSIT, LORAN-C) starting 1972-01-01 in order that they could continue to provide a continuous count of elapsed seconds since their inception. TAI - 10 corresponds to the number of second markers with nameable time tags that have been broadcast by radio broadcast time signal systems that conform to CCIR recommendation 460 since its inception on 1972-01-01. -- 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
On 12 Nov 2020, at 18:02, Paul Gilmartin via tz <tz@iana.org> wrote:
Hello, TZ,
In: ftp://ftp.iana.org/tz/tz-link.html I read: The tz code and data support leap seconds via an optional "right" configuration, ...
Empirically, this seems to assume time_t of TAI-10. This isn't GPS, which I understand to be TAI-19: http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_utc...
TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock.
I find a couple references to "zoneinfo/right" in Makefile and NEWS. Is there more complete documentation of "right" and its rationale elsewhere?
What's missing, I think, from the other replies is the reason the Posix epoch is only approximately 1970-01-01 00:00:00. It's because Posix explicitly defines a day to be 86400 seconds so that, basically, a programmer that wants "this time tomorrow" can just do "time(0) + 86400" and not worry about it. The choice, I think, was between fixing all existing programs to go via a struct tm and, to not put too fine a point upon it, "lying". ("Fixing" a kernel would have been interesting.) Of course, it gets messy with having, for example, the last second of the year twice and code that cares about the encore second has to work hard to deal with it. The consequences have been quite far reaching from that original decision: it's one of the reasons clock_gettime() has clocks for finding out whether it's time for lunch and clocks for determining how long lunch actually lasted. Less prosaically, it's why at least one program that used getttimeofday() as an interval timer panicked when an sub-second interval not so much short as negative. (The bug is now fixed, but the hideous workarounds are still being employed because no one is sure if it is actually fixed and no one wants to find out one dark and stormy night.) jch
On Nov 12, 2020, at 18:46, John Haxby <john.haxby@oracle.com> wrote:
Of course, it gets messy with having, for example, the last second of the year twice and code that cares about the encore second has to work hard to deal with it. The consequences have been quite far reaching from that original decision: it's one of the reasons clock_gettime() has clocks for finding out whether it's time for lunch and clocks for determining how long lunch actually lasted. Less prosaically, it's why at least one program that used getttimeofday() as an interval timer panicked when an sub-second interval not so much short as negative. (The bug is now fixed, but the hideous workarounds are still being employed because no one is sure if it is actually fixed and no one wants to find out one dark and stormy night.)
Ok, I have to ask: what was the program? And, thank you to all who have been contributing to this intriguing and most illuminating discussion. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|
On Fri, Nov 13, 2020 at 5:41 AM Fred Gleason <fredg@paravelsystems.com> wrote:
On Nov 12, 2020, at 18:46, John Haxby <john.haxby@oracle.com> wrote:
Of course, it gets messy with having, for example, the last second of the year twice and code that cares about the encore second has to work hard to deal with it. The consequences have been quite far reaching from that original decision: it's one of the reasons clock_gettime() has clocks for finding out whether it's time for lunch and clocks for determining how long lunch actually lasted. Less prosaically, it's why at least one program that used getttimeofday() as an interval timer panicked when an sub-second interval not so much short as negative. (The bug is now fixed, but the hideous workarounds are still being employed because no one is sure if it is actually fixed and no one wants to find out one dark and stormy night.)
Ok, I have to ask: what was the program?
Our authoritative DNS server for one: https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-.... It led to changes in the Go standard library: https://go.googlesource.com/proposal/+/master/design/12914-monotonic.md. I wouldn't say this bug admits of being fixed so much as being a perpetual trap for the unwary that the library authors have wisely decided to disarm. Sincerely, Watson Ladd
And, thank you to all who have been contributing to this intriguing and most illuminating discussion.
Cheers!
|---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|
participants (12)
-
Brooks Harris -
Fred Gleason -
Guy Harris -
John Haxby -
John Sauter -
Kevin Kenny -
Michael H Deckers -
Paul Eggert -
Paul Gilmartin -
Steve Allen -
Tony Finch -
Watson Ladd