> 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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
