On Jul 5, 2005, at 6:18 PM, Sam Vilain wrote:
Craig DeForest wrote:
Using the TAI epoch of 1958-01-01 00:00:00 has several advantages:
- TAI is recognized by international standards-setting bodies
(BIPM).
- Perl6 will then shake out the 31-bit time rollover a full 12
years before ...
I like this in principle, however I wonder of the merits of
professing to
return something of more accuracy than can actually ever be
realistically
assured from any of the platforms Perl runs.
Hmmm.... Actually, ntpd achieves that sort of accuracy -- but if I
understand
correctly it anchors the UTC time to the standard, and allows the UNIX
seconds count (which often does not account for new leap seconds, though
some gmtime versions account for old ones) to drift or jump whenever
a leap
second goes by. The problem is then that interval calculations that
include the
leap second are off by one second. That probably doesn't bother most
people
but is an endless cause of hassle in scientific applications.
There is also a certain joy that comes from noticing that a tool was
designed by pedants:
it's great that cal(1) handles the Gregorian reformation correctly
(or at least, in one
of several arguably correct ways) even though most of us don't deal
with dates in 1752.
So, er, I guess I'm arguing that time/date stamps, if kept in numeric
counting-ticks form,
should follow TAI in some easily definable way, which probably means
keeping track
of leap seconds in a table that can be updated easily. Even if the
only interface most
people use is through UTC or civil time via the equivalent of gmtime
(), IWBNI the
underlying engines knew enough to work well for those people who do
care about
representing time at such high precision that leap seconds matter.
If the code is
implemented with enough care to do that right, then the natural epoch
to use is probably
1958, though as you pointed out the epoch itself is much less
important than the decision
about what kind of time to track.
Cheers,
Craig
