Re: [Ntp] Leap second draft

[Warner Losh <[e-mail]>]

On Mon, Jan 27, 2020 at 8:56 AM Watson Ladd <[e-mail]> wrote:

>
>
> On Mon, Jan 27, 2020, 12:38 AM Martin Burnicki <
> [e-mail]> wrote:
>
>> Patrik Fältström 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].
>>
>
No. You can't have 61. That's a mistake. It can never be 61, you can't have
double leap seconds. You've made an off by one error here. In fact, it's
about the only leap second mistake POSIX has fixed.

The fundamental problem here is that the formula assumes that there are no
leap seconds. You can't get away from that, so any application of that
formula for what to do during a leap second, which POSIX says doesn't
exist, can't be done.

The reason you get the answer you do is due to a property of gmtime/timegm
that allows one to get a time, and then get a later or earlier time from
that time by incrementing the appropriate field. So if I get a time where
tm_sec=59, I get the next second by adding 1 to tm_sec to get 60. But you
could also add 10 to tm_min to get a time 10 minutes in the future. The
trouble is that neither of these operations returns the proper value across
a leap second. In large part because the proper value may be different
things to different people: some want exactly 10 minutes later (so 600
seconds), while others want the same time hands 10 minutes in the future
and if there's a leap second inbetween, then the interval is one second
longer (so 601 seconds).


> Yes, you can set tm_sec to 61, but how should the conversion function of
>> the runtime library know that it shoudld return second 61 of the current
>> day instead of second 0 of the next day? In POSIX there is no way I'm
>> aware of that can be used to tell the conversion function that a
>> specific second is an inserted leap second.
>>
>
> Operating systems with the ntp_adjtimex system call do return leapsecond
> info. This includes linux and the *BSDs.
>
> System call interfaces can be extended if we have needs here.
>

The problem is more fundamental. It's not just about getting time stamps
that somehow can be known / flagged to be the leap second, but also
propagating that information.

Let's say I touch a file during the leap second. I'd want ls -l to show
that it was changed at 23:59:60 on that day.

So how does a filesystem that stores its times as seconds since 1970 encode
that? It can't. So I can't get that. And even if it stores it in TAI, then
the kernel has to have a leap second table back to 1972 that's up to date
at all times. This is in addition to the timezone files which also need to
be up to date. Then the kernel can translate the TAI times back to UTC.
Except, surprise, there's no unique encoding for a leap second so you're
still stuck...

And let's say we want to force the kernel to return TAI time, which some
have proposed, and we paper over it by creating new system calls to get
this TAI time (or use clock_ API that has provisions for it already). Then
what?  Well, there's about two dozen system calls that return UTC time that
would need TAI time variants. And then you'd want to create a
taitime/timetai to mirror timegm/gmtime. But you'd still have the math
problem referenced above, so you'd need two sorts of compute future time
functions (interval vs offset I talked about above). And you'd need good
timezone data. And you'd need to update it on the running system, or you'd
limit up time to ~18 months on the average. The problems aren't just
getting a timestamp. They run much deeper and are more fundamental. The
twin assumptions of UTC and there are no minutes with 61 seconds run quite
deep and show up in bizarre places.

And that's ignoring legacy code that doesn't follow the normal paths. And
it also ignores a bit of how to exchange time because we've still not
invented any metadata that goes along with the timestamp to ensure that
it's sense (timezone / timescale if you will) is preserved.

So, yea, sorry to be mr grumpy, but this is by no means just a problem of
getting the right time during a leap second. The data flows and the data
formats conspire together to make it hard. And that's why we have the evil
smearing leap seconds because breaking the frequency domain, if done slowly
enough, breaks little to nothing except correspondence to national lab time
which some folks need for regulatory compliance, which can actually be
back-computed for people that really care at least...

This is why high quality ntpd servers return 'unsynchronized' as Martin has
patiently explained, during a leap second so the remote knows it got a
response (so the time server isn't down) and at the same time knows it
should throw it away as being ill-timed. His explanation was much better
than mine and got more of the details right than my recollections from long
ago did.

Warner


>
>
>>
>> Martin
>> --
>> Martin Burnicki
>>
>> Senior Software Engineer
>>
>> MEINBERG Funkuhren GmbH & Co. KG
>> Email: [e-mail]
>> Phone: [phone]
>> Linkedin: https://www.linkedin.com/in/martinburnicki/
>>
>> Lange Wand 9, 31812 Bad Pyrmont, Germany
>> Amtsgericht Hannover 17HRA 100322
>> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
>> Andre Hartmann, Heiko Gerstung
>> Websites: https://www.meinberg.de  https://www.meinbergglobal.com
>> Training: https://www.meinberg.academy
>>
>>