On 2018-07-20 18:05, Stephen Scott wrote:
While there is no perfect answer, it seems that Microsoft Azure
servers got it right for the last one, incorporating the leap second
just before midnight local time.
No, they didn't.
A leap second describes a discontinuity in the function TAI - UTC.
For the last leap second,
the value TAI - UTC was 37 s since TAI was 2017-01-01T00:00:37,
and for some
time before that, it was 36 s until TAI reached 2017-01-01T00:00:36.
The standards do _not_ say when exactly TAI - UTC switched from 36
s to 37 s, but it must have
been between the TAI values 2017-01-01T00:00:36 and
2017-01-01T00:00:37, inclusive, as can
be inferred (perhaps with some good will) from IERS Bulletin C52 of
2016-07-06 (the official
specification of this leap second).
The time interval between these TAI values (excluding the TAI value
2017-01-01T00:00:37) is called
a positive leap second; the corresponding UTC values are denoted
(in ISO 8601 format) with
second values >= 60 (as specified in ITU-R TF.460-6 of 2002).
This is true everywhere near the surface of the Earth, even for
Kiritimati. So Kiritimati
had its last leap second when every other location on the Earth had
it, that is,
when TAI went from 2017-01-01T00:00:36 to just before
2017-01-01T00:00:37,
and UTC went from 2016-12-31-23:59:60Z to just before
2017-01-01T00:00:00Z; so that local time
went from 2017-01-01T13:59:60+14 to just before
2017-01-01T14:00:00+14 during that leap second.
HTH.
Michael Deckers.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
