New definition of "Seconds Since the Epoch" in POSIX

[Paul Eggert]

> Date: Thu, 07 Feb 2002 18:05:43 +0000
> From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
> 
> 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.


Yes, and the POSIX 1003.1-2001 rationale is even more explicit than
the official standard on this point.  Here's a quote from
<http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap04.html#tag_01_04_14>:

   It is a practical impossibility to mandate that a conforming
   implementation must have a fixed relationship to any particular
   official clock (consider isolated systems, or systems performing
   "reruns" by setting the clock to some arbitrary time).

   Note that as a practical consequence of this, the length of a
   second as measured by some external standard is not specified. This
   unspecified second is nominally equal to an International System
   (SI) second in duration. Applications must be matched to a system
   that provides the particular handling of external time in the way
   required by the application.

Also, the POSIX editors went through the standard and replaced most
instances of the phrase "seconds since 00:00:00 UTC (Coordinated
Universal Time), January 1 1970" with "seconds since the Epoch".  I
think it's clear that the intent was that a POSIX system could use UTS
<http://www.cl.cam.ac.uk/~mgk25/uts.txt> rather than UTC.


> 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.

I don't see why that requirement prohibits a system with a TAI time_t
that has 86400 seconds per day.  Suppose we make the usual assumption
that the TAI time_t and UTC time_t values are identical on 1972-01-01,
which means the two time_t values differ by 22 seconds now.  Then, on
a TAI-based system, "date -u" would output "Thu Feb 7 23:24:22 UTC
2002" at the same time that that a conventional UTC-based system would
output "Thu Feb 7 23:24:00 UTC 2002".  As I see it, that's consistent
with the intent of the new standard.

POSIX does require that gmtime use an 86400-second day, and that
gmtime must return UTC, and I think this does prohibit a system that
uses TAI time_t.  However, this gmtime requirement seems to prohibit
UTS time_t as well, and I don't think this was intended.  POSIX
1003.1-2001 is a large new spec, with quite a few bugs (e.g. <time.h>
allows tm_sec to be 60, which means it does allow leap seconds!), so
it wouldn't be surprising if some interpretation requests were needed
to shake out some of the problems here.