Re: Unix timestamp maximum

> AG>> By the time we close in on 2038 and UNIX is still around > AG>> (*smile*) then most UNIX systems will most probably have moved > AG>> to 64bit timestamps, thus requiring in the best place just a > AG>> recompilation of your PHP binary and in the worse case if you > AG>> saved binary file stamps to a file, some kind of conversion > AG>> script. It's not as bad as the Y2K bug (which wasn't too bad:) > > Well, seeing that most Unix concepts are alive from 60-70th till today, > they'll probably be there in 2038. And I'm not sure all systems will be > upgraded by then. But I would probably be retired already by then, so why > should I care? ;) What happens to, for example, somebody who takes out a policy that matures in 40 years and the maturation date is stored in an Oracle database using PHP? To start with, if the date (>2038) was stored with PHP (using mktime), it would come out as -1 If it was stored some other way and then retrieved with PHP (using date), it would show the incorrect date (2038). I know the bug is not PHP's fault, but surely the code for the date related functions could be rewritten so as NOT to use the OS's built-in functions (which I suppose is what is happening at the moment?) Regards, Keith