Zefram scripsit:
> Readings of UT1 et al are most naturally represented as a real count of
> rotations since some epoch (i.e., as some form of Julian Date).
Such a claim cannot be evaluated without reference to a purpose.
> Because TT, TAI, et al are measures of time unrelated to planetary
> rotation, it is misleading to apply to them the day-based notations
> (such as the sexegesimal time-of-day notation) that are customarily used
> with UT1 et al.
Almost anything *may* be misleading.
> Readings of linear time scales (TT, TAI, et al) are most naturally
> represented as a real count of SI seconds since some epoch.
Such a claim cannot be evaluated without reference to a purpose.
> Post-1972 UTC, counting TAI seconds while maintaining a "day" cycle that
> closely matches the phase of UT1, is directly analogous to calendars
> that count days while maintaining a "year" cycle that closely matches
> the phase of the tropical year.
If this means that leap seconds and leap days are analogous, then I
suppose so. If it means something else, I don't understand it.
> Readings of UTC cannot be directly represented by a single linear count.
Of course they can be. The question of what you can do with that
linear count is another matter.
> Unix time, as standardised by POSIX and as commonly implemented, is a
> faulty encoding of UTC. The fault is that Unix time readings repeat,
> and so are ambiguous, near positive leap seconds.
"Faulty" is a word implying, well, fault. The no-fault view is that it's
an *ambiguous* encoding. Whether that is faulty cannot be evaluated
without reference to a purpose.
> Some applications assume that Unix time is monotonically nondecreasing,
> or that timestamps are unambiguous, and so are poorly served by the
> encoding of UTC in Unix time.
Unix time (better: Posix time) *is* monotonically nondecreasing,
provided you set it with NTP and not by brute force. The point about
ambiguous timestamps is correct.
> Some applications assume that Unix time is a linear scale suitable for
> interval calculations, and so are poorly served by the encoding of any
> form of UT in Unix time.
You should add "to a precision of 1s". Applications whose precision
requirements are, say, 1 day, don't have a serious problem.
> New applications need a more sophisticated understanding of time than
> is currently standard practice.
Some do, some don't, some couldn't care less.
--
But that, he realized, was a foolish John Cowan
thought; as no one knew better than he cowan_at_ccil.org
that the Wall had no other side. http://www.ccil.org/~cowan
--Arthur C. Clarke, "The Wall of Darkness"
Received on Thu Jun 01 2006 - 05:10:28 PDT