PHP and the Unix 2037 A.D. Epoch Issue

[David T. Ashley]

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.

[Peter Fox]

Re: PHP and the Unix 2037 A.D. Epoch Issue

Following on from Michael Vilain's message. . .[color=blue]
>In article <f3n_f.32362$aa .22902@fe78.use netserver.com>,
> "David T. Ashley" <dta@e3ft.com > wrote:
>[color=green]
>> 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.[/color]
>
>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]
>[/color]
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@eminen t.demon.co.uk.n ot.this.bit.no. html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.dem on.co.uk>

[Wayne]

Re: PHP and the Unix 2037 A.D. Epoch Issue

On Mon, 10 Apr 2006 02:47:57 -0400, "David T. Ashley" <dta@e3ft.com >
wrote:
[color=blue]
>I'm writing a large PHP application that might still be in service in 2037.[/color]

My god... lets hope no PHP application survives that long.
[color=blue]
>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???[/color]

PHP5 already stores dates as 64bit integers.

[Colin McKinnon]

Re: PHP and the Unix 2037 A.D. Epoch Issue

Peter Fox wrote:
[color=blue]
> Following on from Michael Vilain's message. . .[color=green]
>>In article <f3n_f.32362$aa .22902@fe78.use netserver.com>,
>> "David T. Ashley" <dta@e3ft.com > wrote:
>>[color=darkred]
>>> I'm writing a large PHP application that might still be in service in
>>> 2037.
>>>[/color][/color][/color]
<snip>[color=blue]
>
> 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.[/color]

Building your own date handling from scratch seems a bit extravagant.

I often use ISO formatted dates/times (yyyy-mm-dd [hh:mm[:ss]]) and, if I
need to number crunching or change formatting, just pass it over to the
MySQL parser to deal with. I also don't need to worry about whether the
target can calculate negative timestamps, or timestamps before ...erm...
1900ish.

C.

[Tim Roberts]

Re: PHP and the Unix 2037 A.D. Epoch Issue

"David T. Ashley" <dta@e3ft.com > wrote:[color=blue]
>
>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???[/color]

Let's have a reality check. 30 years ago, most programming was still done
via punched cards. Since that time, the PC was introduced, and has moved
from 8-bit, to 16-bit, to 32-bit, to 64-bit.

Even 8 years from now, it will be difficult to buy a non-64-bit computer.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.