Date: Fri, 09 Oct 1998 13:00:37 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> we first have to "conceptually" shrink the borders of the leap second to a zero interval, and then the original leap second timestamp gets trapped at 24:00:00 from where you continue with normal arithmetic. An alternative (probably much more intuitive) model of thought for the same behaviour is the following: TIME_UTC does not count leap seconds as real time. It ignores the time inserted by a leap second. Think of it in the following Image: If you drive with your car along the timeline, think of leap seconds as slippery intervals of the street of time where your wheels block and your odometer (xtime_diff) stops and therefore they ignore the leap second. These models are entertaining, and it's fun to play with the algebra, but I fear that you've been involved with the problem a bit too much, and you need to step back and take a deep breath. We need a model that's simple and easy to explain; the explanations above are neither. So.... why not use the official model instead? Officially, since 1972, UTC-TAI has been a (negative) integer number of seconds, and when a leap second is inserted, UTC-TAI decreases by 1. What this means is pretty simple: on an implementation whose internal clock ticks TAI, the UTC clock ticks right along with the internal clock -- except during an inserted leap second, where the UTC clock is adjusted back by one second. When converting a UTC clock to a printed representation, it's conventional to use :60 for the inserted leap second, but this is merely a notation to indicate that the UTC clock is repeating, much as the German-standard 'A' and 'B' suffixes are notations for repeated local time when the UTC offset decreases. Viewed in this light, struct xtime's TIME_UTC is not really UTC, as TIME_UTC clocks have special values during an inserted leap second, whereas UTC clocks simply go back 1 second. TIME_UTC is therefore a compromise between UTC clocks (which are not monotonic) and POSIX clocks (which have no leap seconds). TIME_UTC therefore suffers the complexity of a solution that is neither fish nor fowl. The struct xtime proposal would be simplified if it didn't use this complicated interface, and instead used either true UTC, or true POSIX. (Of course, both true UTC and true POSIX could be supported, by having two different clock types.) I am dubious about standardizing on a new halfway-between-UTC-and-POSIX clock type that has never been used in practice and which has some nontrivial conceptual problems.