Nero Imhard wrote: >Is that really the Unix way? I always thought that "proper" >implementations didn't step back, but paused the time for a second at >:59:59 (while still having subsequent calls of gettimeofday return >increasing values by adding microseconds as needed).
POSIX implies that the :59:60 second appears identical to the :00:00 second; i.e., the clock steps back at the end of the leap second. The NTP model (and practice of some implementations) says that the clock should step back at the start of the leap second, making the :59:60 second appear identical to the :59:59 second. In either case, if you look only at the integer seconds portion of the clock then you could interpret it as "paused", in that you get the same time_t value for a period of two seconds rather than the usual one, while the time_t value monotonically increased throughout. But if you look at the microseconds from gettimeofday, you see the microseconds values [0,1000000) occur twice in succession, depicting a repeat of a second rather than a pause or an extra-long second. Also worthy of note is Linux 2.4 behaviour, where the integer seconds value is non-monotonic. The time indicated jumps back by a second at about :59:60.005; it's not aligned to the second boundary. This sequence only makes sense if you look at the complete (integer+fraction) time value and treat the discontinuity as a jump of the clock. I've seen it suggested that a leap second could be indicated in the usual Unix structures by having tv_usec take the range [1000000,2000000) or tv_nsec the range [1000000000,2000000000). With the integer seconds value staying at :59:59, this would be mathematically coherent as well as successful in uniquely identifying the leap second. This seems to be what you think is standard behaviour. I'm not aware of anything implementing this mechanism. gettimeofday and friends never do. Also, think about how much would break if it occasionally saw tv_usec/tv_nsec with an `impossible' value. -zefram _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
