On Thu, 2011-01-13 at 12:57 -0800, john stultz wrote: > On Fri, 2011-01-14 at 05:39 +0900, Kuwahara,T. wrote: > > My proposal: Limit the adjustable range of the offset so that leap > > seconds will never occur more than once. (2147.5 seconds would be the > > best choice. :-) > > 2147.5? That's ~36 minutes. > > While I think a limit could be a sensible compromise here. Leap seconds > are limited to every six months. So surely a limit of 86400 (one day), > or 2592000 (30 days) would be more reasonable. Actually. Thinking about this some more (and having to try to rationalize it for Thomas), this doesn't really seem reasonable. If an application wants to adjust the time, we can leave the responsibility to userland to handle compensation for expected or historical leapseconds if they care. Since if you're adjusting the time, especially by a large amount, you're not starting from the correct time value. So expecting the kernel to incorperate historical or planned future leapseconds (outside of the TIME_INS notification from NTP) is silly. Really, in Linux leapseconds do not really exist except for the moment they occur. If a leapsecond occurs, then you set your time back to before the leapsecond, it won't happen a second time. So I don't think we need to enforce a limit. The interface suggested seems totally reasonable to me. I'm happy to hear arguments to the contrary, but they really must be more convincing. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
