Put all your time manipulation code in a module called Y2038::Problem ???
Seriously if you abstract your time code to a single location it will be easy to modify. But realistically Y2038 is only an issue if time_t is still a 4 byte int in 2038. It is quite reasonable to expect that 64 bit machines will be the norm and quite possibly 8 byte ints. In Perl there is unlikely to be a major issue as our use of time is abstracted from the raw 4 byte dependent time_t. As a result in Perl 6.01 in 2038 (Oh what a cynic) the basic time() function could quite easily be modified to return an 8 byte int into a Perl scalar and thus there is not real issue provided that the Perl was comiled with 8 byte int support, etc.
The ugly Y2K hack is to assume that times say < 2147483647 / 2 (make it a small a the number of extra years you want to wring out of your code) represents a rollover so proceed accordingly. This potentially gives you another 34 years worth of mileage out of it - assuming that there are not valid dates before 2004 you are processing in 2038 of course. You could facilitate such ugly hacks by putting all time functions in a module. ie
# get the difference between two epoch times and cope with 2038 sub diff_time { my ( $begin, $end ) = @_; # for now all we need is: return $begin - $end; # Jan 19 03:14:07 2038 we have potential rollovers so require Math::BigInt; # blah }
For those who might wonder why 2038.....
my $zero_hour = 2**31 -1; print "Zero hour is $zero_hour\n"; print scalar gmtime($zero_hour), "\n"; print gmtime($zero_hour+1) ? "OK" . scalar gmtime($zero_hour+1) : 'Oh +dear!';
cheers
tachyon
s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print
In reply to Re: 2038 bug
by tachyon
in thread 2038 bug
by toma
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |