[LEAPSECS] POSIX Time

[Joe Gwinn]

At 10:18 PM -0600 10/10/09, M. Warner Losh wrote:

>In message: <p06240804c6f6cee17012@[192.168.1.212]>

>             Joe Gwinn <joegwinn at comcast.net> writes:

>: >  >Another common source of confusion is that the POSIX Epoch is an instant

>: >>defined in UTC terms,

>: >

>: >... and occurring at a time for which the present form of UTC is

>: >undefined.  I don't think anyone actually attempts to apply the POSIX

>: >time_t definition to pre-1972 (pre-leap-seconds) UTC.  De facto, Unix

>: >timestamps of any significant age cannot be precisely related to UTC

>: >(or TAI or any other precision time scale).  Historical time_t values

>: >can at best only be interpreted as a transformation of vague UT, unusable

>: >for sub-second absolute timing.  (Actually, you won't often see pre-1990

>: >timestamps that are accurate to the minute, let alone precise enough to

>: >distinguish between flavours of UT.)

>:

>: All kinda true, but for the intended use of POSIX Time, the errors

>: are not significant bu the relevant users.  For instance, the UTC

>: definition of the POSIX Epoch (originally defined in terms of GMT) is

>: off by about 80 microseconds (if memory serves).

>

>Yes, time_t is usually talked about in terms of a fake UTC that never

>existed: one where seconds were uniform and there were no steps in the

>time scale.  Neither one of these were true.  About 2 seconds of UTC /

>TAI divergence accumulated during 1970 and 1972.  The delta between

>UTC and TAI was fixed at 10 at the start of 1972.  It on the order of

>80ms shy of 8s on Jan 1, 1970, but I haven't done the math lately.


It's a "fake UTC" only in that people try to make POSIX Time be UTC, 
despite the standard's explicit disclaiming of any such thing.



>Time_t totally lacks the ability to accurately portray the rubber

>seconds that pre-dated 1972.  And that bit of abnormality is usually

>ignored for the sake of simplicity.


The POSIX timescale is explicitly undefined before the Epoch.  This 
is no accident, because for the purpose of the POSIX timescale 
(originally only file modification timestamps), there was and is no 
reason to be able to define times before POSIX itself existed.

The expectation is that people needing to handle timescales before 
and/or unrelated to the POSIX timescale will do so in application 
code.  For example, an astronomer doing computations of time and 
motion handles time as a form of data, and does not expect local time 
on the workstation doing the computation to jump to the time in the 
data now being processed.



>So in many ways UTC and time_t are only superficially similar things.

>time_t is a half-assed attempt to do the right thing for time.  It

>generally works for most people most of the time, but is wrong where

>it doesn't match reality.


POSIX Time (time_t) solves the problems it was intended to solve, but 
may be half-assed in the context of problems that it was never 
intended to solve.  The issue is not that POSIX Time is right or 
wrong, but that it is misapplied.  Screwdrivers don't make very good 
chisels, and chisels don't make very good screwdrivers, even if each 
is the best of its kind.


Joe Gwinn