History of IEEE P1003.1 POSIX time
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