At 10:18 PM -0600 10/10/09, M. Warner Losh wrote:
In message: <p06240804c6f6cee17...@[192.168.1.212]> Joe Gwinn <joegw...@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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
