|The stupid question is the question not asked|
Re: 2038 bugby tachyon (Chancellor)
|on Apr 11, 2003 at 05:19 UTC||Need Help??|
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
For those who might wonder why 2038.....