On Mon, Jan 27, 2020 at 5:35 AM Tony Finch <[email protected]> wrote: > Zefram via LEAPSECS <[email protected]> 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
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
