Hi all



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



http://www.codeproject.com/KB/bugs/T...-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

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/p...disclaimer.htm

On Tue, May 6, 2008 at 10:57 PM, Paul Scott <pscott@uwc.ac.za> 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

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" <quickshiftin@gmail.com> wrote:

> On Tue, May 6, 2008 at 10:57 PM, Paul Scott <pscott@uwc.ac.za> 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*

stephen@thelonecoder.com
http://www.thelonecoder.com

*Continuing the struggle against bad code*
--

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/p...disclaimer.htm

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 <pscott@uwc.ac.za> 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/p...disclaimer.htm
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Quoting "Jon L." <jonllmsed@gmail.com>:

> 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 <pscott@uwc.ac.za> 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/p...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

On Tue, May 6, 2008 at 11:56 PM, Paul Scott <pscott@uwc.ac.za> 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', -5555500000);
Dec-13-1901
php > echo date_create('@-5555500000')->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)

except of course those introduced by umm, human error

-nathan

On Wed, May 7, 2008 at 12:48 AM, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Quoting "Jon L." <jonllmsed@gmail.com>:
>
> 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, 9999 =/

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

-nathan

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

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

*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/p...disclaimer.htm

-----Original Message-----
From: Paul Scott [mailto:pscott@uwc.ac.za]
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, 9999 =/
>

*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 p

-- Chris


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

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

On Wed, May 7, 2008 at 1:11 AM, Paul Scott <pscott@uwc.ac.za> wrote:

>
> On Wed, 2008-05-07 at 00:54 -0600, Nathan Nobbe wrote:
>
> > looks like mine only goes to dec. 31, 9999 =/
> >
>
> *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

On Wed, May 7, 2008 at 11:34 AM, Nathan Nobbe <quickshiftin@gmail.com> wrote:
>
> On Wed, May 7, 2008 at 1:11 AM, Paul Scott <pscott@uwc.ac.za> wrote:
>
> >
> > On Wed, 2008-05-07 at 00:54 -0600, Nathan Nobbe wrote:
> >
> > > looks like mine only goes to dec. 31, 9999 =/
> > >
> >
> > *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

--
</Daniel P. Brown>
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.