In message: <[EMAIL PROTECTED]> Rob Seaman <[EMAIL PROTECTED]> writes: : Warner Losh wrote: : : > leap seconds break that rule if one does things in UTC such that : > the naive math just works : : All civil timekeeping, and most precision timekeeping, requires only : pretty naive math. Whatever the problem is - or is not - with leap : seconds, it isn't the arithmetic involved. Take a look a [EMAIL PROTECTED] : and other BOINC projects. Modern computers have firepower to burn in : fluff like live 3-D screensavers. POSIX time handling just sucks for : no good reason. Other system interfaces successfully implement : significantly more stringent facilities.

But modern servers and routers don't. Anything that makes the math harder (more computationally expensive) can have huge effects on performance in these areas. That's because the math is done so often that any little change causes big headaches. : Expecting to be able to "naively" subtract timestamps to compute an : accurate interval reminds me of expecting to be able to naively stuff : pointers into integer datatypes and have nothing ever go wrong. Well, the kernel doesn't expect to be able to do that. Internally, all the FreeBSD kernel does is time based on a monotonically increasing second count since boot. When time is returned, it is adjusted to the right wall time. The kernel only worries about leap seconds when time is incremented, since the ntpd portion in the kernel needs to return special things during the leap second. If there were no leapseconds, then even that computation could be eliminated. One might think that one could 'defer' this work to gettimeofday and friends, but that turns out to not be possible (or at least it is much more inefficient to do it there). Since the interface to the kernel is time_t, there's really no chance for the kernel to do anything smarter with leapseconds. gettimeofday, time and clock_gettime all return a time_t in different flavors. In short, you are taking things out of context and drawing the wrong conclusion about what is done. It is these complications, which I've had to deal with over the past 7 years, that have lead me to the understanding of the complications. Espeically the 'non-uniform radix crap' that's in UTC. It really does complicate things in a number of places that you wouldn't think. To dimissively suggest it is only a problem when subtracting two numbers to get an interval time is to completely misunderstand the complications that leapseconds introduce into systems and the unexpected places where they pop up. Really, it is a lot more complicated than just the 'simple' case you've latched onto. : A : strongly typed language might even overload the subtraction of UTC : typed variables with the correct time-of-day to interval : calculations. Kernels aren't written in these languages. To base one's arugments about what the right type for time is that is predicated on these langauges is a non-starter. : But then, what should one expect the subtraction of : Earth orientation values to return but some sort of angle, not an : interval? These are a specialized thing that kernels don't care about. Warner