History of IEEE P1003.1 POSIX time

From: <ut1-mail_at_ASTHE.COM>
Date: Thu, 30 Jan 2003 22:38:41 GMT

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\n") 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/\
Received on Thu Jan 30 2003 - 14:49:41 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT