develooper Front page | perl.perl6.language | Postings from July 2005

Re: Time::Local

Thread Previous | Thread Next
From:
Craig DeForest
Date:
July 5, 2005 15:59
Subject:
Re: Time::Local
Message ID:
200507051659.48762.deforest@boulder.swri.edu

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.


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About