Re: [Ntp] Leap second draft

[Warner Losh <[e-mail]>]

On Fri, Jan 24, 2020 at 7:45 AM Patrik Fältström <[e-mail]> wrote:

> On 24 Jan 2020, at 15:12, Warner Losh wrote:
>
> > No. That is wrong. The numbering of the leap second is undefined. This
> is one way to resolve the issue, but it is not the only way. You will not
> find this specified, except indirectly via math on the struct tm, which
> isn't definitive about what to do during the leap.
>
> What I see are two things. First the math:
>
> > If the year is <1970 or the value is negative, the relationship is
> undefined. If the year is >=1970 and the value is non-negative, the value
> is related to a Coordinated Universal Time name according to the C-language
> expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all
> integer types:
> >
> > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
> >     (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
> >     ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
>
> Then the definition of tm_sec which can have values [0,61].
>
> So far, so good, and the number of seconds in a day with an added leap
> second will then be 86401, and the first second of the following day (the
> following second) will have the same value.
>
> Where I agree with you that the leap second is undefined is the plain text
> which says:
>
> > As represented in seconds since the Epoch, each and every day shall be
> accounted for by exactly 86400 seconds.
>
> This implies that even if the math gives 86401 seconds (including the fact
> tm_sec can have a value of 61), the value 86401 seconds in a day is not
> valid.
>

Yes. It's ambiguous. A POSIX time_t is not defined at the leap second. You
could use your math to get one answer. However, that answer, back
translated to a struct tm gives the wrong day, so is also incorrect. In
POSIX land, leap seconds don't exist, and any definitive statement about
the 'proper' time_t encoding for a leap second cannot be made. It's
undefined.

Warner