Quoth Darren Duncan on Tuesday 05 July 2005 04:20 pm,
> I believe that at its core [the time/date] object should simply store a 
count of
> rigorously defined time units relative to a rigorously defined epoch.
> What the epoch is and what the time unit is will need to be
> officially defined (eg, Jan 1, 2000; counting in fractions of
> seconds).  The object should not store anything other than this
> single numerical value internally (smart caching of conversions
> aside).

Agree agree...

Hmmm....  Straight seconds-counting has the flavor of international atomic 
time (TAI) to it, which suggests using the TAI (rather than UNIX) epoch.

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 
the rest of the UNIX-speaking world. :-)
        - TAI is sufficiently different from UNIX time to make implementors 
carefully about their time conversion software.  This is important because 
some UNIX implementations handle leap-seconds and others don't, and this is a 
nice chance to get everything Right the first time.
        - TAI-to-UT conversion modules can easily ingest leap-second 
without further conversion to a different time base (see, e.g.,  This is important 
because, without proper maintenance of the leap-second table, all of our 
perl6 calendar programs will run an hour late a mere 500 years from now.

Reply via email to