[LEAPSECS] Windows Server 2019

Michael Deckers Michael.Deckers at yahoo.com
Mon Jul 23 17:39:30 EDT 2018



    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.



More information about the LEAPSECS mailing list