Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]] wrote:
>
> On Wed, Aug 16, 2000 at 09:49:36AM -0400, Stephen P. Potter wrote:
> > Lightning flashed, thunder crashed and Jonathan Scott Duff
> <[EMAIL PROTECTED]> whispered:
> > | Um, it's not guaranteed to blow up in 2038. That's an
> implementation
> > | detail. IF we implement our time values as 64-bit integers (for
> > | instance), we'll long out-live the 2038 deadline.
> >
> > I don't know about anyone else, but I don't intend to care
> by the time the
> > 2038 deadline comes around. ;-) I hope to still be alive
> and enjoying my
> > grandchildren by then, but I really hope to not be still
> programming!
>
> That must sound awfully similar to what the COBOL programmers in the
> 60's said when they figured that two digits is enough :-)
>
And the 2038 deadline won't hit us in 2038, it will do it evil work long
before that.
I have been hit by it some years ago, trying to calculate the 67'th
birthday of a person that was 18 years old.
Solution: switch to the Date::Calc module for all date calculations
and just use time() for short term timings, where the range is just
a few days.
This way the epoch just doesn't matter! Is would be nice for time() to
return a value that has a good precision (1 second is normally not enough),
and a reasonable range (eg a dozen centuries each way from now).
Henrik Tougaard - FOA, Denmark.
