Re: [Ntp] Leap second draft

[Warner Losh <[e-mail]>]

On Thu, Jan 23, 2020 at 4:09 PM Warner Losh <[e-mail]> wrote:

>
>
> On Thu, Jan 23, 2020 at 4:04 PM Watson Ladd <[e-mail]> wrote:
>
>>
>>
>> On Wed, Mar 27, 2019, 9:47 AM Daniel Franke <[e-mail]> wrote:
>>
>>> I'm writing up an I-D clarifying how NTP implementations are to behave
>>> in proximity to a leap second and also introducing an extension field
>>> that provides better leap-second-related information than is
>>> expressible using header fields alone, including giving the TAI-UTC
>>> offset.
>>>
>>> Karen, you mentioned a possible CfA for
>>> draft-stenn-ntp-extended-information if Harlan revises it to comply
>>> with RFC 7822 (-04 does not appear to comply). Our two drafts are
>>> partly redundant in purpose since they both provide TAI-UTC offset and
>>> we won't want to adopt both. Of course I think mine is the one we
>>> should adopt, but I'll strive to get a -00 submitted promptly so that
>>> they can be considered side-by-side without unduly delaying Harlan's
>>> CfA.
>>>
>>
>> Apologies for the necromancy but someone at work just asked me which
>> second is repeated in an NTP timestamp and to make sure all our sources use
>> the right one.
>>
>
> NTP timestamp repeats the last second of the day. Once without the leap
> bit set and then again with it set.
>

Ah, the standard doesn't say this...  It just says that the values can be
subtracted, so forget I said anything about NTP


> POSIX doesn't specify, and so systems choose a number of different ways of
> coping (repeat the last second of the day, repeat the first second of the
> next day, freeze time during leap second, do some crazy smear to pretend
> reality matches the POSIX spec, kernel panic, etc).
>

This part is true. It's the biggest flaw with time_t: It doesn't
acknowledge that leap seconds exist, so what to do during that thing which
the standard says doesn't exist is up for grabs :(

Warner