On Wed, 2005-08-17 at 01:28 -0500, Dave Rolsky wrote: > > Why on earth would you want to encourage such a short sighted > > programming practise? The earth wobbles like a spinning top. In fact > It's hardly short sighted to want leap seconds to be abandoned (not in > Perl but world wide). The few people who _really_ care about syncing to > midnight can still have them, but the rest of the world would be just fine > with a leap hour every couple hundred years.
Well, right now one of the great things about looking at the wall to read the clock and see the time, is that you know that based on the time of day and the time of year, and where you are, roughly how far through the actual solar day it is. It's crude, but useful. Just ask a Dairy Farmer. What else do you want the time of day to represent? You would prefer it something completely arbitrary, just to make it easier to program with? That we don't just use a straight solar clock is probably down to the fact that it was technically infeasible to have one without a sundial, which obviously doesn't work at night or in England. > > alternate times. Environments that really can't guarantee an absolute > > epoch can simply return unanchored times and let the modules throw > > exceptions when you try to convert them to real times or times with > > impossible levels of accuracy. > Great, so now code that works in one environment throws a "cannot find an > up-to-date leap seconds table" exception in another? Eek! Well, only if you try to do something silly like ask for the number of seconds between two points of time in different days a long time in the future, where those times were composed from Gregorian components. If you were to ask for the number of minutes, or not cross the boundary of when leap seconds are allowed, then it would still be OK. I would expect a similar exception if I tried to calculate the number of hours between two dates in an unknown timezone. Of course feel free to consider this all worthless heckling, given the lack of time I've been putting towards an implementation of all this ;). Sam.
