[LEAPSECS] Leap seconds have a larger context than POSIX

[Warner Losh]

On Sat, Feb 1, 2020 at 10:57 PM Seaman, Robert Lewis - (rseaman) <
rseaman at email.arizona.edu> wrote:

> Tried to send this a few days ago, but it never showed up on the list.
> Steve has provided gritty details since.
>
>
>
> Since roughly the second world war, the distinction between time-of-day
> and interval-time has become increasingly clear. But the history of this
> distinction goes back at least as far as Galileo. UTC was an attempt to
> serve both Universal Time (time-of-day) and Atomic Time (interval timing)
> using a single standard.
>

UTC is one solution, but it's :60 second is a wart it invented in 1972 with
no consultation with the rest of the world.  To say it's universal really
misses the point that it's just a good approximation of a Universal time
that's handy for some group of people, but difficult for others. It was
changed in the lifetime of many on this list. It could change again to be a
better fit with changing times. There should be nothing sacrosanct about it
as it was invented out of whole cloth 48  years ago. It was unprecedented
at the time, and for the first 35 or so years the difficulties of
implementing it for computers were unknown because computers didn't keep
time well enough for it to matter. Now they do.


> Folks in this thread are focusing on the difficulties of this scheme, but
> UTC has had significant success as well. Nobody would be trying to build on
> top of it if this were not true. One reason UTC has succeeded is because
> of  its design implementing Universal Time, not in spite of it.
>

I'd argue one reason it's been successful is that it papers over the issues
with seconds changing length to get universal time. I think the important
part of UTC is thee C part not the UT part. So long as everybody agrees on
what time it is, and that time is close to the Solar time, we're good. We
have lots of timezones, especially in Russia, that are more than an hour
different than mean solar time. This suggests that time of day relative to
the sun has a tolerance for almost everybody of around an hour, which
suggests a UTC++ plus timezones that can keep things within an hour is
fine, which leaves a lot of wiggle room, though there will be winners and
losers to any change.


> It seems bizarre to have to state that it would be wise to fully analyze
> civil timekeeping engineering requirements before making any changes. Some
> here have participated in a variety of meetings and discussions with this
> goal, but I am unaware of any external funding for such activities. Other
> communities have invested much greater time (so to speak) and money
> regarding similarly ubiquitous, yet esoteric, standards and protocols.
>

Part of that analysis should necessarily include the impact on computing as
well

If the precision timekeeping community had adopted the proposal from the
> 2003 Torino symposium to define the new time scale called TI, we would have
> had 17 years to cover the Earth like locusts. Instead the intervening
> period has been squandered trying unnecessarily to undermine UTC. Recipe
> for success:
>

>
>    1. Define a new time scale and leave UTC alone for future
>    compatibility. Your own systems engineering requirements likely include
>    time-of-day.
>
> Except nobody will use this. We already have a dozen different time scales
without leap seconds. Nobody uses them outside a niche. Everybody inside
that niche translates the niche time scale to UTC for displaying to users.


And people have tried running kernel time in TAI time.  It didn't work.
Even when  you try  to be compatible, there's dozens of problems that make
it hard because it's not just POSIX time_t that's at issue (though within
the kernel it's bad enough). It's the fact that things like filesystems
specify an elapsed time since an epoch in a time scale without leap
seconds. Every FAT or NTFS disk around has a time like this. So conversion
of kernel TAI times to UTC or these other time scales requires perfect
knowledge of leap seconds, and conversions more than 6 months in the future
are ambiguous at best.


>
>    1.
>    2. There are two kinds of time and timekeeping. All successful systems
>    engineering will start from this simple fact.
>
>
> Whatever POSIX does with leap seconds should be in a larger and more
> coherent global concept of timekeeping.
>

POSIX can't do leap seconds. That ship has already sailed. It's more than
just POSIX as it is baked into almost all storage formats today. Even if we
could fix that issue, there are significant operational issues with ticking
in TAI since a full leap table is required to convert TAI times to UTC.

If it were just what is returned by the kernel during a leap second, that
might be solvable (smearing NTP shows that's possible). But given the
mutually exclusive demands on timestamps and their arithmetic properties,
it's impossible to fix without significant breakage. A cost/benefit
analysis likely would conclude the cost to, say, eliminate leap seconds
from UTC (and for the purposes of argument, UTC here means the time that's
official everywhere, regardless of name). I'd wager actually fixing all the
software out there would run into the billions. Replacing steering systems
for telescopes is likely somewhat less than that.

But up until this point, I've just pointed out that leap seconds can't
possibly exist inside of POSIX time_t, by definition and what this friction
means. I've not advocated for changes to UTC.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200202/5aa28913/attachment-0001.html>