Re: [PHP-DEV] Unix timestamp maximum

[teo]

Hi Stanislav!
On Wed, 04 Apr 2001, Stanislav Malyshev wrote:

> 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? ;)
> 
Haven't you seen "Cowboys in space?" 
you will be called back to save the world from Y-0x07f6 Bug!
:))

-- teodor

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Unix timestamp maximum

[Phil Driscoll]

>Ideally it should not depend an operating system structure.
Agreed (but quite a lot of work I think).
>I propose #define PHP_DATE_SIZE _int64
Not agreed, unless you move the start date backwards a few thousand years :)
Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Unix timestamp maximum

[Joe Brown]

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" <[EMAIL PROTECTED]> wrote in message
001501c0bd43$bd9215a0$d47cfea9@home">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 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Unix timestamp maximum

[Keith Waters]

> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Unix timestamp maximum

[Stanislav Malyshev]

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? ;)

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Unix timestamp maximum

[Andi Gutmans]

By the time we close in on 2038 and UNIX is still around (*smile*) then 
most UNIX systems will most probably have moved to 64bit timestamps, thus 
requiring in the best place just a recompilation of your PHP binary and in 
the worse case if you saved binary file stamps to a file, some kind of 
conversion script. It's not as bad as the Y2K bug (which wasn't too bad:)

Andi

At 05:06 PM 4/4/2001 +0200, Keith Waters wrote:
>From: [EMAIL PROTECTED]
>Operating system: RedHat Linux
>PHP version:  4.0.4pl1
>PHP Bug Type: Feature/Change Request
>Bug description:  Unix timestamp doesnt go over Tuesday 19 January 2038
>05:11
>
>As you know, most of PHP's date and time functions use the unix
>timestamp, which wont go past Tuesday 19 January 2038 05:11, numberically
>represented by 2147483648 (ie 30 bits)
>
>Surely PHP can get clever and work around this? (ie allow bigger values
>which will translate back and forth properly up to the year ?)
>Otherwise we will all find outselves with a Y2K-like date nightmare!
>
>eg:  currently:  echo mktime(0,0,0,1,1,2099);  outputs -1
>and putting any number past 2147483648 into date() wont give you
>anything past Tuesday 19 January 2038 05:11
>
>Thanks!
>regards,
>Keith
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]