As one of the main people who worked on time related aspects of the IEEE P1003.1 POSIX standard, I'd like to make a few comments about how it came to be the way it is now.

First I'd like to tell you about the early consensus on time; before any of the POSIX time specs were written. I'm not saying I agree or disagree with that consensus. These were just the cards that were "glued to the table" that our time sub-committee was forced to deal with: Initially there was a proposal to require the timestamps returned from system calls such as time(2) to yield the exact number of seconds since the time known as the Un*x epoch. This calculation included the known leap seconds at the time. Unfortunately at the time nearly all Un*x implementations did NOT take seconds into account. For example, there were a non-trivial number of file system i-nodes and dump tapes that used a "trivial seconds since the Epoch" calculation. Distributing leap second tables and requiring hosts to be "on-line" to receive them in those days (when UUCP over slow baud modems was common) was not considered realistic. It was felt expect vendors and/or system administrators to maintain a complete leap second table (including leap seconds announced in advance) was also considered unrealistic. The POSIX decision was to preserve existing practice. That the vast majority of time-stamp calculation methods ignored leap seconds . The decision was to to continue to use a trivial seconds since the Epoch" calculation that ignored leap seconds. It was also decided that IEEE P1003.1 POSIX should not demand that a host's clock be accurate. In those early days the system time was typically set by the system administrator's watch. Your typical Un*x hardware clock drifted like hell. Many hosts used nothing more than the occasional system administrator adjustment to fix a really bad clock. Eyeballing a second hand of a wall clock was typical. Use of rdate (*ick*), let alone the much better ntp protocol was not a common practice. The committee did not want the fact that the system clock may be poorly set and/or rather inaccurate to make the system non-conforming. They did not want to require vendors to fix or even improve their clock systems. In addition these "glued to the table" cards, there were a number of unfortunate attitudes: "Don't confuse people with UTC. Everyone uses GMT and knows what it means". "Lets not complicate things by worrying about the fact that the year 2100 is not a leap year." "You mean the year 2000 is, but 2100 is not a leap year?" "Everyone knows there are only 60 seconds in a minute." "I'm lucky if my system's clock is accurate to the minute, so I could care less about sometime as small as a leap second". "It takes hours, sometime days, for my EMail message to reach most people. Why should I worry about something as small as a second?" "What matters to me is just that POSIX systems produce the same ctime(3) string (i.e., Wed Jun 30 21:49:08 1993

") when given the same time(2) time-stamp." "SI? TAI? UT1? I'm having trouble with using UTC instead of good old GMT!". Given these cards: 1) We produced a formula that calculated "seconds since the Epoch" without respect to leap seconds. I.e., the formula did not take into account known leap seconds when converting a something like a 'struct tm' (where time is expressed in year, day, hour, minute, second) into a time-stamp. This proposal was largely accepted. However the formula taking into account 100/400 leap year rule was rejected as being not necessary since 32 bit signed timestamps would run out years before the year 2100. 2) We defined the epoch as "1970 Jan 1, 00:00:00 UTC". This was defeated and UTC was replaced with GMT. 3) We defined things like tm_sec (the number of seconds after the minute) as ranging from 00 thru 60. This was defeated and the limit of 59 was restored. Sometime later, when POSIX was a big fight over signals and job control, our sub-committee: 1) Requested that POSIX epoch from GMT-based to a "1970 Jan 1, 00:00:00 UTC" Epoch. We argued that UTC was an international standard and therefore using UTC would make be required if POSIX were to become an ISO level standard. The draft standard was changed to use UTC in place of GMT. A comment was put into the standard that "GMT and UTC were effectively the same thing" (not MY choice of words ... but at least POSIX now said UTC!). It too a few drafts to change all of the GMT's to UTC's. Some GMT's came back by force of habit. And we did have to explain who "Coordinated Universal Time" was UTC and not CUT a few times. Early on after the draft said UTC, several people tried to change it to CUT. 2) Requested that POSIX expand the range for things such as tm_sec (the number of seconds after the minute) to allow for values 00 thru 60. We wanted a POSIX system that was presented with a "23:59:60" name for a leap second to not reject it. To our surprise the idea of the seconds value being something like "60" went through without objection. I suspect that the fact at the time-stamp for "23:59:60" == "00:00:00 of the next day" time-stamp by virtue of the "seconds since the Epoch" formula helped. 3) We proposed adjusting the "seconds since the Epoch" formula to account for the 100/400 leap year rule. This was defeated. At the time too many people wanted to get back to fighting over System V vs. BSD signals and did not want to even hear our reasoning. We put a poison comment into the standard telling people that the "seconds since the Epoch" formula would go wrong after Feb 28, 2001. Finally in the 2001 version, the 100/400 leap year rule was put into place. I can clearly state that: The IEEE P1003.1 POSIX uses the term "seconds since the Epoch" represent the non-leap seconds since "1970 Jan 1, 00:00:00 UTC". POSIX timestamps use the POSIX "seconds since the Epoch" formula. After 2001, the POSIX "seconds since the Epoch" formula was corrected to deal with the 100/400 leap year rule. The standard does not require your system clock to be accurate. When a leap second occurs, unless your POSIX system makes the effort to adjust its clock (say via the adjtimex(2) call), your POSIX system's clock will ignore the leap second. I was not 100% happy with the result ... it was the best one could get given the majority. We did have a number of who POSIX voters tried to improve time related matters during the ballot process, but nearly all of those proposals were defeated. =-= And for my 2-cents worth: I am am favor of keeping current leap second model. I am not in favor of quasi-adjustments such as fixed leap-second intervals. I want UTC to be leap second adjusted so that |UTC - UT1| < 0.9 seconds. The Universe is full of things beyond our control such as all of Earth's wobblies, nutations, drifts, precisions and a host of chaotic motions. People should be used to our chaotic Universe. If they want their names for "points in time" to have some vague relationship to their physical universe, then they should not demand that process to determine the names for "points in times" be nice, clean, and infinitely predictable. Just my opinion! chongo (Landon Curt Noll) /\oo/\