Re: [PHP] the Y2K38 BUG

2008-05-07 Thread Daniel Brown
On Wed, May 7, 2008 at 11:34 AM, Nathan Nobbe <[EMAIL PROTECTED]> wrote:
>
> On Wed, May 7, 2008 at 1:11 AM, Paul Scott <[EMAIL PROTECTED]> wrote:
>
>  >
>  > On Wed, 2008-05-07 at 00:54 -0600, Nathan Nobbe wrote:
>  >
>  > > looks like mine only goes to dec. 31,  =/
>  > >
>  >
>  > *Gasp!* best you get cracking on finding an alternative solution!
>
>
>  yes, me and the rest of the immortal gang are all quite worried :O

It matters nil.  We're all dead anyway.  There's indisputable
evidence that "Crisis 38", as I've dubbed it, will be man's doom.

http://isawit.com/y2k38.php

-- 

Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedicated servers, VPS, and hosting from $2.50/mo.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] the Y2K38 BUG

2008-05-07 Thread Nathan Nobbe
On Wed, May 7, 2008 at 1:11 AM, Paul Scott <[EMAIL PROTECTED]> wrote:

>
> On Wed, 2008-05-07 at 00:54 -0600, Nathan Nobbe wrote:
>
> > looks like mine only goes to dec. 31,  =/
> >
>
> *Gasp!* best you get cracking on finding an alternative solution!


yes, me and the rest of the immortal gang are all quite worried :O

-nathan


RE: [PHP] the Y2K38 BUG

2008-05-07 Thread Chris Haensel
-Original Message-
From: Paul Scott [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 07, 2008 9:12 AM
To: Nathan Nobbe
Cc: Kalle Sommer Nielsen; Jon L.; Chetan Rane; php-general@lists.php.net
Subject: Re: [PHP] the Y2K38 BUG


On Wed, 2008-05-07 at 00:54 -0600, Nathan Nobbe wrote:

> looks like mine only goes to dec. 31,  =/
> 

*Gasp!* best you get cracking on finding an alternative solution!

--Paul

I'm building my apps for my
grand-grand-grand-grand-grand-grand-grand-grand-grand-grand-grand-grand-gran
d-grand-grand-grand-grand-grand-grand-grand-grand-grand-grand-grand-grand-gr
and-grand-grand- children, so I better get on this :op

-- Chris


http://www.burning-turf.com http://www.phpstop.com

There is much pleasure to be gained from useless knowledge.
Bertrand Rusell


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] the Y2K38 BUG

2008-05-07 Thread Paul Scott

On Wed, 2008-05-07 at 00:54 -0600, Nathan Nobbe wrote:

> looks like mine only goes to dec. 31,  =/
> 

*Gasp!* best you get cracking on finding an alternative solution!

--Paul

All Email originating from UWC is covered by disclaimer 
http://www.uwc.ac.za/portal/public/portal_services/disclaimer.htm 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Nathan Nobbe
On Wed, May 7, 2008 at 12:48 AM, Kalle Sommer Nielsen <[EMAIL PROTECTED]> wrote:

> Quoting "Jon L." <[EMAIL PROTECTED]>:
>
>  Another possibility...
>> Port the Date object implementation from ECMA/Javascript.
>> It has a range of +/-8.64e15, or Tue, 20 Apr -271821 00:00:00 GMT to Sat,
>> 13
>> Sep 275760 00:00:00 GMT.
>>
>> You know...just to have a little extra time to find something else. ;)
>>
>> - Jon L.
>>
>
> That would be a quite interesting move, try propose it to Derick ;)


looks like mine only goes to dec. 31,  =/

php > echo date_create('-12-31')->format('M-d-Y');
Dec-31-
php > echo date_create('1-1-01')->format('M-d-Y');
Jan-01-2000

-nathan


Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Nathan Nobbe
On Tue, May 6, 2008 at 11:56 PM, Paul Scott <[EMAIL PROTECTED]> wrote:

>
> On Tue, 2008-05-06 at 23:50 -0600, Nathan Nobbe wrote:
> > true-that ;)
> > anyway, the DateTime class is implemented as a 64-bit unsigned (i think)
> > value.  so if you use it you should be good to go.
> >
> > php > echo date_create('2040-10-24')->format('M-d-Y');
> > Oct-24-2040
> >
>
> a 64bit unsigned int is best, but that would only work properly on 64bit
> arch. For 32bit users, making it unsigned is the best option for now,
> and I suppose that by 2038 there will be another option.


i put "i think" only because im not 100% on the implementation, though i
know it has something to do w/ 64-bits; and it does seem to support a
massive range of dates on a 32-bit system.  and also, there is good reason
to use it, if for example you have dates that are prior to dec 13, 1901.
the standard date() stuff chokes on anything earlier than that.  and even
now, i have dealt with applications doing date arithmetic that spilled over
2038, breaking existing logic.

php > echo `uname -p` . PHP_EOL;
AMD Athlon(tm) XP 1500+

php > echo date('M-d-Y', -50);
Dec-13-1901
php > echo date_create('@-50')->format('M-d-Y');
Dec-14-1793


> As far as I am concerned, this discussion is a discussion for the sake
> of discussion. If I am still using the same apps that I use today in
> 2038, I will officially rethink my usefulness as a human being :)


as far as im concerned ive committed to using DateTime ever since i learned
of its superior internal implementation.  that way i dont have to deal with
silly bounds related limitations in my date time calcs, ever (practically
speaking) :D

except of course those introduced by umm, human error ;)

-nathan


Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Kalle Sommer Nielsen

Quoting "Jon L." <[EMAIL PROTECTED]>:


Another possibility...
Port the Date object implementation from ECMA/Javascript.
It has a range of +/-8.64e15, or Tue, 20 Apr -271821 00:00:00 GMT to Sat, 13
Sep 275760 00:00:00 GMT.

You know...just to have a little extra time to find something else. ;)

- Jon L.


That would be a quite interesting move, try propose it to Derick ;)



On Wed, May 7, 2008 at 12:56 AM, Paul Scott <[EMAIL PROTECTED]> wrote:



On Tue, 2008-05-06 at 23:50 -0600, Nathan Nobbe wrote:
> true-that ;)
> anyway, the DateTime class is implemented as a 64-bit unsigned (i think)
> value.  so if you use it you should be good to go.
>
> php > echo date_create('2040-10-24')->format('M-d-Y');
> Oct-24-2040
>

a 64bit unsigned int is best, but that would only work properly on 64bit
arch. For 32bit users, making it unsigned is the best option for now,
and I suppose that by 2038 there will be another option.

As far as I am concerned, this discussion is a discussion for the sake
of discussion. If I am still using the same apps that I use today in
2038, I will officially rethink my usefulness as a human being :)

--Paul


All Email originating from UWC is covered by disclaimer
http://www.uwc.ac.za/portal/public/portal_services/disclaimer.htm


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php






Kalle Sommer Nielsen
Danmarks Radio - www.dr.dk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Jon L.
Another possibility...
Port the Date object implementation from ECMA/Javascript.
It has a range of +/-8.64e15, or Tue, 20 Apr -271821 00:00:00 GMT to Sat, 13
Sep 275760 00:00:00 GMT.

You know...just to have a little extra time to find something else. ;)

- Jon L.

On Wed, May 7, 2008 at 12:56 AM, Paul Scott <[EMAIL PROTECTED]> wrote:

>
> On Tue, 2008-05-06 at 23:50 -0600, Nathan Nobbe wrote:
> > true-that ;)
> > anyway, the DateTime class is implemented as a 64-bit unsigned (i think)
> > value.  so if you use it you should be good to go.
> >
> > php > echo date_create('2040-10-24')->format('M-d-Y');
> > Oct-24-2040
> >
>
> a 64bit unsigned int is best, but that would only work properly on 64bit
> arch. For 32bit users, making it unsigned is the best option for now,
> and I suppose that by 2038 there will be another option.
>
> As far as I am concerned, this discussion is a discussion for the sake
> of discussion. If I am still using the same apps that I use today in
> 2038, I will officially rethink my usefulness as a human being :)
>
> --Paul
>
>
> All Email originating from UWC is covered by disclaimer
> http://www.uwc.ac.za/portal/public/portal_services/disclaimer.htm
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Paul Scott

On Tue, 2008-05-06 at 23:50 -0600, Nathan Nobbe wrote:
> true-that ;)
> anyway, the DateTime class is implemented as a 64-bit unsigned (i think)
> value.  so if you use it you should be good to go.
> 
> php > echo date_create('2040-10-24')->format('M-d-Y');
> Oct-24-2040
> 

a 64bit unsigned int is best, but that would only work properly on 64bit
arch. For 32bit users, making it unsigned is the best option for now,
and I suppose that by 2038 there will be another option. 

As far as I am concerned, this discussion is a discussion for the sake
of discussion. If I am still using the same apps that I use today in
2038, I will officially rethink my usefulness as a human being :)

--Paul

All Email originating from UWC is covered by disclaimer 
http://www.uwc.ac.za/portal/public/portal_services/disclaimer.htm 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Stephen Johnson
Seriously If your apps are still being used in 2038 ... WOW!

This is an issue that will more then likely be well resolved LONG before
2038... 


On 5/6/08 10:50 PM, "Nathan Nobbe" <[EMAIL PROTECTED]> wrote:

> On Tue, May 6, 2008 at 10:57 PM, Paul Scott <[EMAIL PROTECTED]> wrote:
> 
>> 
>> On Wed, 2008-05-07 at 10:03 +0530, Chetan Rane wrote:
>>> Have guys heard of the the Y2K38 Bug more details are on this link
>>> 
>> 
>> Nope, but I can guess what its about.
>> 
>>> Can there be a possible solution. As the system which I am developing
>>> for my client uses Unix timestamp.
>>> 
>> 
>> There are probably multiple solutions. AFAIK time is a 32 bit signed
>> int, making it unsigned would add like 100 years onto your app.
>> 
>>> This might effect my application in the future
>>> 
>> 
>> If your app survives that long! Why not just maintain it and when times
>> change, your app changes? :)
>> 
>> Seriously, this is really not a big deal!
> 
> 
> true-that ;)
> anyway, the DateTime class is implemented as a 64-bit unsigned (i think)
> value.  so if you use it you should be good to go.
> 
> php > echo date_create('2040-10-24')->format('M-d-Y');
> Oct-24-2040
> 
> -nathan

-- 
Stephen Johnson
The Lone Coder

http://www.ouradoptionblog.com
*Join us on our adoption journey*

[EMAIL PROTECTED]
http://www.thelonecoder.com

*Continuing the struggle against bad code*
--



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Nathan Nobbe
On Tue, May 6, 2008 at 10:57 PM, Paul Scott <[EMAIL PROTECTED]> wrote:

>
> On Wed, 2008-05-07 at 10:03 +0530, Chetan Rane wrote:
> > Have guys heard of the the Y2K38 Bug more details are on this link
> >
>
> Nope, but I can guess what its about.
>
> > Can there be a possible solution. As the system which I am developing
> > for my client uses Unix timestamp.
> >
>
> There are probably multiple solutions. AFAIK time is a 32 bit signed
> int, making it unsigned would add like 100 years onto your app.
>
> > This might effect my application in the future
> >
>
> If your app survives that long! Why not just maintain it and when times
> change, your app changes? :)
>
> Seriously, this is really not a big deal!


true-that ;)
anyway, the DateTime class is implemented as a 64-bit unsigned (i think)
value.  so if you use it you should be good to go.

php > echo date_create('2040-10-24')->format('M-d-Y');
Oct-24-2040

-nathan


Re: [PHP] the Y2K38 BUG

2008-05-06 Thread Paul Scott

On Wed, 2008-05-07 at 10:03 +0530, Chetan Rane wrote:
> Have guys heard of the the Y2K38 Bug more details are on this link
> 

Nope, but I can guess what its about.

> Can there be a possible solution. As the system which I am developing
> for my client uses Unix timestamp.
> 

There are probably multiple solutions. AFAIK time is a 32 bit signed
int, making it unsigned would add like 100 years onto your app.

> This might effect my application in the future
> 

If your app survives that long! Why not just maintain it and when times
change, your app changes? :)

Seriously, this is really not a big deal!
>  
> 
> Thank you, in Advance.

It's a pleasure my paranoid son...

--Paul

All Email originating from UWC is covered by disclaimer 
http://www.uwc.ac.za/portal/public/portal_services/disclaimer.htm 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] the Y2K38 BUG

2008-05-06 Thread Chetan Rane
Hi all

 

Have guys heard of the the Y2K38 Bug more details are on this link

 

http://www.codeproject.com/KB/bugs/The-Year-2038-Bug.aspx

 

Can there be a possible solution. As the system which I am developing for my
client uses Unix timestamp.

This might effect my application in the future

 

Thank you, in Advance.

 

 

With Regards

 

Chetan Dattaram Rane

Software Engineer

 

 

 

<>