Re: Unix timestamp maximum

Excellent example Keith. In order for PHP to gain acceptance in the commercial communities, a date limitation will certainly prevent that. Date limitation on "only" this or that operating system does not support any argument. Ideally it should not depend an operating system structure. I propose #define PHP_DATE_SIZE _int64 "Keith Waters" <keith@waters.co.za> wrote in message news:001501c0bd43$bd9215a0$d47cfea9@home... > > 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: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >