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
before
the rest of the UNIX-speaking world. :-)
- TAI is sufficiently different from UNIX time to make implementors
think
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
announcements
without further conversion to a different time base (see, e.g.,
ftp://62.161.69.5/pub/tai/publication/leaptab.txt). 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.
