Mark Calabretta wrote on 2005-08-05 07:53 UTC:
> You are saying that POSIX time, unix system time, is UTC, right?
> http://en.wikipedia.org/wiki/Unix_time supports that but apparently
> POSIX time keeping is a bit of a shambles - check Steve Allen's web page
> http://www.ucolick.org/~sla/leapsecs/onlinebib.html or the man page for
> time(2). (It also begs the question - why does unix maintain a table of
> leap seconds?)
POSIX timekeeping is not really "in shambles". The current phrasing of
the standard was selected after long and careful deliberations on the
difference between TAI and UTC. It reads:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14
"4.14 Seconds Since the Epoch
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 is
implementation-defined. As represented in seconds since the Epoch, each
and every day shall be accounted for by exactly 86400 seconds.
Note:
The last three terms of the expression add in a day for each year
that follows a leap year starting with the first leap year since the
Epoch. The first term adds a day every 4 years starting in 1973, the
second subtracts a day back out every 100 years starting in 2001, and
the third adds a day back in every 400 years starting in 2001. The
divisions in the formula are integer divisions; that is, the remainder
is discarded leaving only the integer quotient."
So POSIX says in other words:
- The term "Seconds since the epoch" (which is elsewhere used to define
the meaning of the time_t type used in various API calls) is defined
to represent an integer encoding of a YYYY-MM-DD hh:mm:ss display
of a clock display that approximates UTC.
- It leaves the question of how accurate this approximation of UTC has to be
in relation to "true UTC" up to the implementation (sensible, because
no every implementation has good knowledge of UTC; not everyone uses or
cares about NTP, GPS, etc.).
- It leaves the question of what to do near a leap second up to
the implementation (sensible, because not every implementation has
good knowledge of UTC or of upcoming leap seconds). It leaves space
for other specifications (such as UTS) to fill that gap, by defining
the exact behaviour of an implementation that knows about highg-accuracy
UTC and forthcoming leap seconds.
In other words, POSIX does not require you to hook up your computer to a
GPS receiver, if you don't want to.
More on UTS:
http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Fri Aug 05 2005 - 05:12:40 PDT