In message: <[EMAIL PROTECTED]> Rob Seaman <[EMAIL PROTECTED]> 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