[LEAPSECS] leap seconds in POSIX

[Warner Losh]

On Mon, Jan 27, 2020 at 5:35 AM Tony Finch <dot at dotat.at> wrote:

> Zefram via LEAPSECS <leapsecs at leapsecond.com> wrote:
> > Hal Murray wrote:
> > >I assume the basic idea would be something like switch the kernel to
> use TAI
> > >rather than UTC and implement conversion in some library routines.
> >
> > That's not a viable approach, because of the wide range of uses to which
> > time_t is put.
>
> In particular, the kernel needs time_t for compatibility with filesystems
> that need it, and other non-syscall interfaces that expose time_t. There's
> a lot of them.
>

Yes.  The problems are legend.

First, there are the 'return time' system calls or legacy routines. These
aren't so bad. You can make new ones: gettimeofday, settimeofday, time.
Then, you need gmtime and timegm except for TAI. The goal here being that
you use either all old, or all new routines.  The new routines are just
like the old, so that seems to work because there's no leap seconds.
clock_getime has the ability to have a CLOCK_TAI even.

Except that the gmtime routines are still not quite right. time_t <->
struct tm is still lossy. So, to really fix the problem you need to either
enhance struct tm to carry metadata of the sort of timezone (since UTC is
almost a time zone). and then you need to think hard about what to do with
gmtime/taitime wrt leap seconds. So you'd need to fix the 'feature' of
gmtime/timegm that you can do things like add to the different tm_* fields
to move time forward. But that starts to intrude into real code changes.
Otherwise, you can't represent a leap second.

And then there's functions like stat, utimes, futimes, that have time_t
burried in them as struct timeval or struct timespec. If you want to change
the interpretation of those values (which is currently UTC), you'd need new
versions of those system calls that return TAI time. And you'd have to be
careful too: nanosleep(2) and select(2) doesn't need a new version since
its timeval is an interval, not an absolute time. There's some like the
clock_* routines that don't need to change too. In FreeBSD I counted about
two dozen instances that would need to be audited.

And then you have to worry about filesystems. What happens if I'm building
software during the leap second? Regardless of how you shoe-horn the time
into place, you can wind up with a situation where the source is newer than
the object for things like generated files, which will confuse make. So now
you need to have a bunch of routines in the kernel to convert historical
UTC times to TAI times, which means you need all leap seconds that have
ever happened to do it right (remember, we added system calls to get this
data in TAI not UTC above). And that's not even getting into external
things like NFS that need to do this over the network (though largely, it's
the same problem).

And so now you're left with a data management problem. You have to update
the timezone files, because that's how you paper over UTC enough to make
the old routines work (except during a leap second). And you have to invent
mechanisms to keep them up to date in long running programs (otherwise
those slowly diverge in systems with long uptimes). And so you have to be
connected to the internet (or some other data stream) to make the updates.
And if you're making updates in place, you have to do it atomically so you
don't race.

And even if you do all that, it's impossible for me to get the TAI time for
any times > 6 months out (technically the other side Dec 31 or June 30)
because we have no clue what that time will be. We find out in January if
there's a leap in June, so future time values in June can't possibly be
right if you are doing them in December. Sure, you can pull out the 'use
struct tm or its replacement' for such times so far in the future, but
that's kinda arbitrary since times 3 months in the future are fine...
Unless the system has been disconnected from its data sources for some
reason...

So sure, you can half-ass something that solves some of the problems, but
it's a huge undertaking to do it all right. And there's huge resistance to
being this intrusive into the system just to fix a silly problem once every
couple of years. Why slow things down the other half billion seconds
between leap seconds.

It's not a simple problem at all to get completely right.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200127/4b729557/attachment.html>