[LEAPSECS] leap seconds in POSIX

[Brooks Harris]

On 2020-02-01 3:01 AM, Hal Murray wrote:
> tvb at LeapSecond.com  said:
>> I see some good comments; did you get the answer you wanted?
> Nothing off list, so you have seen everything that I saw.
>
> I was hoping that there would be a good white paper or blog that discussed all
> the possibilities that have been considered and explained why they were
> rejected.
>
> -------
>
> Probably crazy idea dept...
>
> Has anybody considered having time_t and the kernel keep smeared time?
>
> The idea is that you can convert from smeared time to TAI or UTC with leaps.
> So a few new library routines should be enough for the few people who care
> about leap seconds.
>
>
The inconvenient truth is that atomic time is a constant frequency 
phenomenon and mean solar time is a variable frequency phenomenon.

It would be straight forward to define a variable frequency timescale 
that represented mean solar time very closely based on UT1. Each day 
would have 86400 "seconds" in its YMDhms representation. Such a scale's 
frequency would diverge from UTC frequency by only 5 ppb, a precision 
below most systems ability to discern. However, the "seconds" of the 
YMDhms representation would not be SI seconds and would not match the 
UTC YMDhms, placing the midnight day boundary very slightly different 
from the UTC midnights. It would probably satisfy the purposes of 
computer time, civil time, celestial navigation, many astronomers, and 
it would preserve the age old tradition of timekeeping by the Sun.

But suggestion of such a variable frequency scale is anathema to the 
timing community (BIPM, IERS, etc) and unacceptable for GNSS navigation 
and many engineering purposes such as industrial control, including the 
industry I come from, the television business. Timekeeping laws all over 
the world presume adherence to UTC as defined by ITU-R Rec 460. It's not 
so much a technical problem as a political argument, the same debate 
that raged during the 1960s and resulted in the constant frequency 
definition of UTC we have today. There are two parts to the insistence 
on constant frequency dissemination; 1) there can be one and only one 
timescale and 2) this timescale must disseminate constant frequency SI 
seconds. These criteria are politically immovable objects. This leads 
the 'great leap-second debate' ongoing and unresolved since 1999.

Google Smear (and others) work around the practical problem by slewing 
the frequency of their NTP servers across a 24 hour period so the 
receiving systems never 'see' the leap-second.

Leap Smear
https://developers.google.com/time/smear#example_of_the_standard_smear

This works to avoid potential failure due to possible faulty leap-second 
implementations throughout the system but results in ambiguous 
timestamps during the smear. Note they say "The long duration keeps the 
frequency change small. The change for the smear is about 11.6 ppm. This 
is within the manufacturing and thermal errors of most machines' quartz 
oscillators, and well under NTP's 500 ppm maximum slew rate.". Note this 
is 86400 / 86401 = 0.9999884, 1 - 0.9999884 = 0.0000116.

The frequency of a variable frequency timescale based on UT1 would vary 
from UTC by 5 ppb worst case, currently running closer to 1 ppb, ~four 
orders of magnitude lower that Google Smear, and traceable to UTC with a 
precision <10 ns. It would be something very close to what was once 
called GMT.

But, as one colleague has put it, anyone suggesting such a solution 
would be sent home without dinner. So you didn't hear it from me.

-Brooks