Re: [LEAPSECS] Introduction of long term scheduling

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sun, 07 Jan 2007 14:10:35 -0700 (MST)

In message: <C6914BB9-0057-4C47-8404-2268C6D15B93_at_noao.edu>
            Rob Seaman <seaman_at_NOAO.EDU> writes:
: What is correct is to have a 61 second minute occasionally, neither
: to redo the first second of the next day, nor to repeat the last
: second of the current day.

Unfortunately, that's not POSIX time_t. And when you are implementing
unix kernel APIs, that is the only game in town, unless you invent
your own. ntp_gettime comes close to implementing things right (on
FreeBSD the time state is synchronous to top of second), but even that
is a mess.

You can't do both 61 second minutes and also have the 'naive math'
that time_t requires.

I agree with others that have said that ntp should be TAI or GPS based
(eg a linear count of seconds in a timescale that doesn't have leap
seconds), and that leap second corrections should happen in userland
like is done for timezones. That's really the only sane way to do
things. Having tried it, there are a lot of little 33 second
anomolies in many applications :-(. I've toyed with the idea of
running the kernel in TAI and having 'smart' processes tell libc they
want no UTC translation and having all the TAI<->UTC translation
happen in libc (also hacking those FS that want UTC time to be able to
get it). Maybe I'll try it and see what breaks since the line between
applications and libraries can make a per-process flag hard to cope
with if your application links with a lot of libraries.

Warner
Received on Sun Jan 07 2007 - 13:14:06 PST