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.
For a start, to convert from the available time source - the system clock
- to TAI, you need to know;
a) current adjustments, or when the lack of adjustments is considered
valid up to (after that date, of course, if the list of adjustments
is not updated, getting the time or converting from a time to a date
on a calendar is an exception).
b) whether or not the system clock is automatically correcting for
leap seconds, ie when ntpd is running and sync'ed up.
In any case, I'll add "to_TAI" as one of the marshalling methods for
Date objects in Date.pm
I guess it comes down to what guarantees we decide to make on the nature
of time(). If a leap second passes while the script is running, can the
value returned by time() regress?
In fact, do we even need a fixed epoch? Why not just free-wheel it and
make 0 the time the script started, get it to count seconds, and let
interfaces for the system clock / orson database solve the hard problems.