Front page | perl.perl6.language |
Postings from August 2005
From: Sam Vilain
August 17, 2005 22:32
Message ID: firstname.lastname@example.org
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
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 ;).