Re: [PHP] the Y2K38 BUG
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
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
-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
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
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
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
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
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
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
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
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
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
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 <>
