On Thu, Mar 04, 2004 at 09:12:47AM -0500, Dan Sugalski wrote: : At 7:30 PM -0800 3/3/04, TOGoS wrote: : > > Interesting -- so the planet's finally gotten : >> its act together and settled on a rotational : >> speed, huh? Cool. :) : > : >Nobody said anything about a planet. : : Actually, they did. UTC (which was the original reference) is defined : such that noon is within .9 seconds of the sun being as directly : overhead as it can be, and is thus directly tied to the behaviour of : the planet.
The basic problem is that there are times you need to know exactly how many seconds have passed between two timestamps, and times you need to know exactly how many days have passed between two timestamps, and the two are in conflict. However, I think the more basic problem of the two is the first one. If you ignore that problem, you get all sorts of breakage down in random routines that you don't want breakage in, and this will only get worse as computers get faster, and try to syncronize more low level things. In contrast, the other problem tends to manifest in user interfaces, where it can typically be solved by some snap-to-grid semantics at the minute, hour, and day boundaries, at least until the second timer and the Earth drift apart by 30 seconds or so. Which will take a while. And anyone who needs greater UTC accuracy than that should probably be tracking TAI-UTF offsets anyway, or have some other way of resyncing their clock at least semiyearly. So anyway, I don't care whether Parrot builds in support for complicated time systems like UTC. (Well, I do care some--it should probably be a library in any event.) But I do care that C<time - $^T> be accurate. (In fact, I'd like $^T to change to a floater too, on systems that can support it. It's way past time for hi-res timing to be the default, I think.) Larry
