[LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Warner Losh]

On Mon, Jul 25, 2016 at 7:56 AM, Martin Burnicki
<martin.burnicki at burnicki.net> wrote:
> Tony Finch wrote:
>> Martin Burnicki <martin.burnicki at burnicki.net> wrote:
>>>
>>> IMO a better approach would be to let the system time run on TAI, and do
>>> the conversion to UTC, and local time in the next step, by runtime
>>> libraries.
>>
>> The kernel needs to know UTC for things like filesystem timestamps.
>
> I know. This is mainly to avoid ambiguities you'd have with time stamps
> in local time, as under plain old DOS.
>
> Using TAI for the file time stamps should be fine as well, it would even
> avoid ambiguities for files which are written during a leap second. Of
> course, if the kernel could *tell* the time stamps are TAI instead UTC
> then tools like 'ls' could display the TAI timestamps in UTC, if required.

This is a great idea, except it's impossible. :(
The POSIX defined APIs are such that there's THE timestamp for the file
and it's, by definition UTC. There's no way to say these files have a TAI
timestamp and those have a UTC timestamp. And if it did, the impact would
be huge. Make(1) would need to change to cope with the 40 second difference,
as would many other programs that compare the system time to a file time
or file times to each other.

And then there's the external storage format requirement. Most systems specify
UTC as the format, either directly or in a de-facto way because time_t is pretty
close to UTC (technically UT(unspecified)).

Third, you'd alway need to have current, perfect knowledge of leap seconds to
start the system. Or you'd have to accept errors that flow from this.
The first time
you need to convert a UTC timestamp to TAI you'll have issues downstream if
there was a leap second that you somehow missed. Do you have an API to tell
others that you lied to them in the past and to correct things? Or do you live
with the errors (errors designed in, which is a big problem with time_t today).

And then there's a class of applications that deals in 'future times'.
If your knowledge
of leap seconds change after you've asked for a time to be converted
from UTC to TAI
then that TAI time is off by a second. or 40 if you lose your leap
second table. This
is a minor problem when running a well connected system, since
timestamps more than
a month in the future are rarely requested (but do sometimes happen)
and usually you
can propagate the new leap info before people start asking for it. But
if not, what do you
do? If you tell me "It's only a second error" I'm going to punch in
the face. That's
the same lousy attitude that's lead to the hodge-podge of half-assed
almsot solutions
that we have today.

And then there's the 'cold spare' issue. If I have a deployed system
that had a number
of spares sitting on the shelf to be swapped in when the primary
component fails, then
those systems won't know the new leap second information when they first come up
and will need to acquire it. In the case of a cold GPS receiver, this
can takes minutes
which delays the recovery of the system. In one system I deployed, we had to go
to great lengths in this case to find the current leap information
from other local systems
(since we weren't connected to the internet). Otherwise, ships could
run aground (it was
a timing system for navigation control).

And then there's the long running process issue. With the current time
libraries,
the tables are loaded at startup, but never again. So, if you have an
application
that needs to know about leap seconds, and you'd hope to use the timezone files
to cope, you'll find that you need to hack the standard libraries to
implement periodic
reload to get the right information. Once you do, you have the issues
described above
for new information.

Many things right now in the kernel depend on UTC being right very
early. If you delay
that, then other things will be wrong. Any filesystem that has to
store dates in UTC won't
be able to update them until you know what UTC is. This can cause
sequencing issue if
you have to write any files before you get this knowledge.

Sure, you can do a half-assed job of papering over these problems, but they are
the problems you'll have if you go the TAI route.

The problem is so much more than just display. And unless it just
works by default,
there will be problems. In the past the answer has been 'well, special
needs people
need to go to extra lengths' which has been a huge cop-out. They already do, and
the challenges of implementation and logistics can be extensive.

> If you insist that file times should be UTC then the kernel could
> convert the TAI time stamps to UTC before writing the file time stamps.

Only if it has perfect knowledge of all leap seconds ever. Otherwise you make

> For example, ntpd already passes the TAI offset down to the kernel if it
> knows this number, e.g. from a leap second file, or via autokey from an
> NTP server.

that helps, but it's only the first step on a long journey.

Warner