The new 2001 edition of the POSIX standard (IEEE Std 1003.1-2001) is now freely available online: http://www.UNIX-systems.org/version3/ Of particular interest to all you leap second gurus out there is perhaps the new slightly revised/relaxed definition of the technical term "Seconds Since the Epoch" that forms the basis for the scalar time used in Unix system calls: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_0... A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time are made is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. What has changed? Apart from adding the mod 100 years and mod 400 years leap year rules to the formula, the last two paragraphs have been added. These essentially relax the definition of Seconds Since the Epoch. Without them, a strict interpretation of the old definition would have required that a UTC-aware implementation (e.g., an NTP-synchronized workstation) has to show the same progression of values during an inserted leap second 23:59:60Z and the following first second of the next day 00:00:00Z. In other words, the wording of the old definition could have been interpreted to require UTC-synchronized POSIX clocks to show the same scalar timestamp at 23:59:60.5Z as well as one second later at 00:00:00.5Z, which is indeed what for example the Linux kernel did when connected to a reference clock with activated kernel PLL. The new definition relaxes that and allows for example an implementation to decide to implement the progression of the scalar system time near an inserted leap second by slowing down the system clock briefly, for example according to the formula proposed in http://www.cl.cam.ac.uk/~mgk25/uts.txt As I read it, the new definition still prevents implementations from making the system's scalar time an exact measure of physical time (e.g. by applying the provided encoding formula to a TAI clock display, instead of a UTC clock display) by the requirement of representing each day by an increment of 86400 "seconds" on the scalar clock. (Though nitpickers could of course argue that the text does not explicitely refer to a UTC day, I know :-) Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>