[Ntp] Antw: Re: Leap second draft

["Ulrich Windl" <[e-mail]>]

>>> Warner Losh <[e-mail]> schrieb am 24.01.2020 um 16:42 in Nachricht
<CANCZdfqDqYdP+Z9ais3puWqoKJz0DbjmUCPn5gkSYNo=[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.

I think that is the major bug in POSIX leap seconds: While time_t is the
internal representation of time, struct tm is only the human-readable
representation. Leap seconds were based on the human representation (61st
second in minute), while most software works with the internal representation.
So converting between both representations is not unique.


> 
> Warner