On 2020-02-01 3:01 AM, Hal Murray wrote:
[email protected] 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
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
