[LEAPSECS] Leap seconds have a larger context than POSIX

[Warner Losh]

On Tue, Feb 4, 2020 at 7:31 AM Brooks Harris <brooks at edlmax.com> wrote:

> On 2020-02-04 2:54 AM, Warner Losh wrote:
> >
> > Have I forgotten any of the other details of leap seconds that are
> > more tribal knowledge than rigorously specified?
> >
> > Warner
> >
> >
> I think another unclear topic is when the value of DTAI ("The value of
> the difference TAI – UTC") is updated. This is not clearly stated
> anywhere and I've heard many discussions about it, including here on
> this list. The question is if DTAI is updated simultaneous with the
> leap-second of after the leap-second. Rec 460 does not state this. The
> answer is evident only by *implication* in Bulletin C and other
> publications. Bulletin C 52, for example, says " UTC TIME STEP on the
> 1st of January 2017", and shows:
> from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
> from 2017 January 1, 0h UTC, until further notice : UTC-TAI = - 37s
>

That's a good point. Lord knows I've thought, in the past, that it
accumulated over the leap second. However, that's not entirely true because
the rules for the irregular radix that embodies UTC are weird and require
much careful thought that often runs against mathematical intuition. I even
had worked out the math to prove his once, only to discover that my 'proof'
was fatally flawed and the only proper way to increase the delta is by
1.0s, exactly, at the end of the leap second. This is all tricky stuff that
should be explicitly specified for a rigorous standard.


> Bulletin C does not say or indicate the value will change with the
> leap-second, but immediately after the leap-second, simultaneous with
> the following midnight. Other publications, such as
> Leap_Second_History.dat show this same relationship. But no prose says
> "the value *shall* update *after* the leap-second".
>

Yes. That's the only way I found to make the math work properly.


> Curiously Bulletin C does not call this "DTAI" as Rec 460 does, and
> gives the value in the opposite sign (Rec 460 calls it "TAI – UTC" and
> Bulletin C calls it "UTC-TAI"). This is an example of the inconsistency
> in the use of terms and nomenclature in the relevant documents at ITU-R,
> BIPM, and IERS, which does not help clarity.
>

That inconsistency doesn't help. There's also the issue that what time
geeks call "T1-T2" is computed by subtracting T2 from T1 because that's
what time counters do and that's a convention that carries over from the
metrological laboratory side of the time keeping business. I suspect that
some of this sloppiness is due to different groups having different
conventions in what they mean, and this disconnect wasn't noticed in the
drafting process.


> Find is a copy of Rec 460 I've modified at:
>
> http://edlmax.com/Common_Calendar/R-REC-TF.460-6-200202-I!!MSW-E_BEH_V1_2019-11_15.doc
>
> I've added minimal prose changes (red) and an addition to ANNEX 3,
> FIGURE 3 to clarify these two issues, 1) that TAI and UTC are to be in
> the YMDhms form, and 2) that DTAI updates after the leap-second. I feel
> if Rec 460 had these small changes it would make the use of leap-seconds
> much more clear and save many hours of discussion and angst. It took me
> a long time to have confidence in my understanding when I first
> encountered the leap-second some years ago.
>

I'll have to read through it. It sounds useful.

One bone to pick, though, is that TAI and UTC are both continuous time
scales, so applying the continuous bit to TAI  seems to imply UTC isn't
continuous. But I think it means continuous in the sense that TAI has been
maintained since that time, without interruption, and that no inference
about UTC should be made. UTC has had small jumps back and forth in the 60s
in the rubber leap second era (which were discontinuities), so perhaps the
wording is a nod to that, but an explicit nod would be better. So there's
two ways to view this and ambiguity is rarely a good thing...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200205/ae9eaeba/attachment.html>