Posted by Peter Fox on 04/10/06 12:51

Following on from Michael Vilain's message. . .
>In article <f3n_f.32362$aa.22902@fe78.usenetserver.com>,
> "David T. Ashley" <dta@e3ft.com> wrote:
>
>> I'm writing a large PHP application that might still be in service in 2037.
>>
>> What will happen to PHP and Unix time ... will there be a version of PHP
>> written for 32-bit platforms that uses 64-bit integers, or is everybody
>> counting on exclusively 64-bit platforms being in service by then???
>>
>> Thanks, Dave.
>
>Well, whoever is still running it will have to hire you to fix it around
>that time, won't they. Imagine the COBOL programmers thinking about
>their date fields in the late 1960's and asking what should be done
>about their programs in 1999?
>
>Any solution anyone comes up with right now will be totally useless in
>20 years. Why don't you worry about global warming and gas prices
>instead? It's probably a better use of your time.
>
>[insert caustic "get a life" phrase here]
>
Now now - No call for that sarky (and misguided) approach.

The issue will arise a long time before '37. For example taking out a
25 year mortgage in 2012. So that's six years before a mortgage
application starts saying that the mortgage company will be paying you
£1000 a month for the next minus35 years. Well worth worrying about.

The obvious answer is to decouple your dates from built-in dates of any
kind (eg by having your own date class) and assume that system clocks
will be fudged nearer the time. This way your program stays independent
of all other limitations.






--
PETER FOX Not the same since the porcelain business went down the pan
peterfox@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[Back to original message]