Yr 2038 on Linux
Moderator: General Moderators
Yr 2038 on Linux
According to the Y 2038 problem the max time for UNIX_TIMESTAMP is 19-Jan-2038, 03:14:07 AM GMT.
But when the date in a MySQL field was 2038-01-19 00:00:00, strtotime() gave -1 on Linux but on Windows it returned a huge number.
Why did this happen ? Are there limitations on Linux ?
According to phpinfo the System is
Linux infong 2.4 #1 SMP Mon Aug 9 10:21:08 CEST 2004 i686 unknown
Thanks
But when the date in a MySQL field was 2038-01-19 00:00:00, strtotime() gave -1 on Linux but on Windows it returned a huge number.
Why did this happen ? Are there limitations on Linux ?
According to phpinfo the System is
Linux infong 2.4 #1 SMP Mon Aug 9 10:21:08 CEST 2004 i686 unknown
Thanks
Was the number in Windows the correct one? (was it the number of seconds since the Unix epoch)?
Irregardless, it's probably just a difference in the implementation between the Linux and Windows versions of PHP. I wouldn't say either one is wrong or broken, just different implementations.
Irregardless, it's probably just a difference in the implementation between the Linux and Windows versions of PHP. I wouldn't say either one is wrong or broken, just different implementations.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
As long as you aren't doing any bitwise operations, when the time comes to migrate MySQL's INT values to something bigger, you should be relatively unaffected. From what I gather the main problem in a fix is binary compatibility: big problem for low level languages eg: C, but not so much for high level languages eg. PHP where memory is managed for you.
Edit: Hmm... I should have read the post better. This post is pretty irrelevant. I'd place my money on "unsigned"
Edit: Hmm... I should have read the post better. This post is pretty irrelevant. I'd place my money on "unsigned"
Btw,
returns 0
Code: Select all
SELECT UNIX_TIMESTAMP('2038-01-19 00:00:00');Code: Select all
echo strtotime('2038-01-19 00:00:00');On the server Linux infong 2.4 #1 SMP Mon Aug 9 10:21:08 CEST 2004 i686 unknown, PHP 4.3.10 it gives -1 !
SELECT UNIX_TIMESTAMP('2038-01-19 00:00:00'); returns 0 in both - My PC and Server !
When it gave this big number in WinXP I expected it to work on Linux.
I have a question, what's going to happen when the date nears 2038, are alternative time functions in the planning? What if I needed to store a date that far into the feature right now in the present time? (perhaps an online reservation system and some one is booking a plane ticket waaaay in advance, heh) What are the alternatives?
Edit: eh, I guess nothing needs to be done in terms of new time storage systems, integer size will increase with time, but still... what if I want to insert a timestamp for 2040, what should I do?
<off-topic>
Do not use. The word is a mistaken fusion of irrespective and regardless.
an erroneous redundancy for regardless.
Irregardless is nonstandard. Use regardless instead.

</off-topic>
Edit: eh, I guess nothing needs to be done in terms of new time storage systems, integer size will increase with time, but still... what if I want to insert a timestamp for 2040, what should I do?
<off-topic>
Google defines as:pickle wrote:Irregardless
Do not use. The word is a mistaken fusion of irrespective and regardless.
an erroneous redundancy for regardless.
Irregardless is nonstandard. Use regardless instead.
</off-topic>
jshpro2 wrote: what if I want to insert a timestamp for 2040, what should I do?
By the time 2038 rolls around, most programs will be running on 64-bit or even 128-bit computers. In a 64-bit program, a time_t could represent any date and time in the future out to 292 000 000 000 A.D., which is about 20 times the currently estimated age of the universe. The problem with this kind of optimism is the same root problem behind most of the Year 2000 concerns that plagued the software industry in previous years: Legacy Code. Even if every PC in the year 2038 has a 64-bit CPU, there will be a lot of older 32-bit programs running on them The greatest danger with the Year 2038 Problem is its invisibility. The more-famous Year 2000 is a big, round number; it only takes a few seconds of thought, even for a computer-illiterate person, to imagine what might happen when 1999 turns into 2000. But January 19, 2038 is not nearly as obvious. Software companies will probably not think of trying out a Year 2038 scenario before doomsday strikes. Of course, there will be some warning ahead of time. Scheduling software, billing programs, personal reminder calendars, and other such pieces of code that set dates in the near future will fail as soon as one of their target dates exceeds 19-Jan-2038, assuming a time_t is used to store them.
Yeah, I realize that, but its not 2040 yet, What if I needed to deal with dates that far into the future, today? what would be the idea alternative. That's what I was trying to askanjanesh wrote:jshpro2 wrote: what if I want to insert a timestamp for 2040, what should I do?By the time 2038 rolls around, most programs will be running on 64-bit or even 128-bit computers. In a 64-bit program, a time_t could represent any date and time in the future out to 292 000 000 000 A.D., which is about 20 times the currently estimated age of the universe. The problem with this kind of optimism is the same root problem behind most of the Year 2000 concerns that plagued the software industry in previous years: Legacy Code. Even if every PC in the year 2038 has a 64-bit CPU, there will be a lot of older 32-bit programs running on them The greatest danger with the Year 2038 Problem is its invisibility. The more-famous Year 2000 is a big, round number; it only takes a few seconds of thought, even for a computer-illiterate person, to imagine what might happen when 1999 turns into 2000. But January 19, 2038 is not nearly as obvious. Software companies will probably not think of trying out a Year 2038 scenario before doomsday strikes. Of course, there will be some warning ahead of time. Scheduling software, billing programs, personal reminder calendars, and other such pieces of code that set dates in the near future will fail as soon as one of their target dates exceeds 19-Jan-2038, assuming a time_t is used to store them.
I cannot find it, despite numerous searches, but I am completely sure (all puns intended) that I read that php5.1 was working on the calendar/datetime handling issues.jshpro2 wrote:I have a question, what's going to happen when the date nears 2038, are alternative time functions in the planning?
Ignoring that, would you believe that its yet another thing that adodb solves?!?!
http://phplens.com/phpeverywhere/adodb_date_library
Supported Date Range
Dates from 100 A.D. to 3000 A.D. and later have been tested. The minimum is 100 A.D. as <100 will invoke the automatic 2-digit => 4-digit year conversion. The maximum is billions of years in the future, but this is a theoretical limit as the computation of that year would take too long with the current implementation of adodb_mktime( ).
It's somewhere at http://www.derickrethans.nl/ as he's the one working on itRoja wrote:I cannot find it, despite numerous searches, but I am completely sure (all puns intended) that I read that php5.1 was working on the calendar/datetime handling issues.jshpro2 wrote:I have a question, what's going to happen when the date nears 2038, are alternative time functions in the planning?