On Wed, Mar 03, 2004 at 04:18:14PM -0500, Dan Sugalski wrote: : >Don't get me wrong--I think the concept of TAI time is great. : >It's just always going to be a fixed number of seconds different than : >Perl 6 time, is all, whatever the TAI time is for Jan 1, 2000, UTC. : : That, as they say, turns out not to be the case. UTC has leap : seconds, TAI doesn't. The two are slowly diverging--off by 32 seconds : right now, and probably off by 33 this year or next, with extra : seconds added irregularly. (It's why the decoded time array's seconds : goes from 0-60 rather than 0-59)
No, I *am* assuming that Perl 6 time tracks TAI time accurately with a constant offset, and drifts with respect to UTC. That does mean that the translations from internal time to real datetimes have to be groomed periodically, and people who don't upgrade their Perl for years on end might find its clock off by a second or two. But just as the cable company forces periodic upgrades into your cable box without your keeping track, any networked Perl ought to be able to install a new time map automatically over the net without much user intervention--but only if we design with that in mind in the first place. But for sanity's sake, to keep the time continuum flat, we have to abandon the notion that Dec 31 is always 86400 seconds long, or any length predictable several years in advance. We can't afford to have off-by-one errors when you subtract two standard Perl 6 times. Larry
