Portable general timestamp format, not 2038-limited

sla29970 at gmail.com sla29970 at gmail.com
Thu Jun 28 16:32:29 CEST 2007

On Jun 27, 10:51 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> According to <http://en.wikipedia.org/wiki/UTC>, UTC is derived from
> TAI.

According to <http://en.wikipedia.org/wiki/TAI>, TAI is a proper time,
but the very first section in the TAI discussion page cites a refereed
paper by the person then in charge of TAI which asserts that is not

As for the primacy of UTC vs. TAI, this is the classical chicken and
egg problem.  The bureaucratic reality is opposed to the physical

> it's always within 20 nsec.  This seems like the kind of correction
> that can be applied after the fact.

It is the nature of horology that *all* clocks need corrections
applied after the fact.  The question is whether a given clock and its
time distribution system is good enough for the given application.

> The difficulty/impossibility of computing intervals on UTC because of leap seconds suggests TAI is a superior timestamp format.

TAI is a superior time scale for processes on the surface of the earth
which only care about nanosecond precision, but it is not practically
available nor legal nor applicable off the surface of the earth.  TAI
is itself corrected after the fact by the issue of TT(BIPMxx).

More information about the Python-list mailing list