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://220.127.116.11/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.