Page 1 of 1
Yr 2038 on Linux
Posted: Thu Jul 28, 2005 11:21 am
by anjanesh
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
Posted: Thu Jul 28, 2005 3:53 pm
by pickle
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.
Posted: Thu Jul 28, 2005 5:34 pm
by timvw
my guess is that your windows version uses a int64 or unsigned int32 and your linux version (signed) int32.
The last half of 2^32 is used for negative numbers...
Posted: Thu Jul 28, 2005 5:35 pm
by Ambush Commander
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"
Posted: Thu Jul 28, 2005 5:41 pm
by timvw
Btw,
Code: Select all
SELECT UNIX_TIMESTAMP('2038-01-19 00:00:00');
returns 0
Posted: Thu Jul 28, 2005 11:03 pm
by anjanesh
Code: Select all
echo strtotime('2038-01-19 00:00:00');
On my PC (32bit Win XP SP2, Apache 2.0.52, PHP 5.0.3) gives
2147452200
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.
Posted: Sun Jul 31, 2005 2:33 am
by josh
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>
pickle wrote:Irregardless
Google defines as:
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>
Posted: Sun Jul 31, 2005 2:45 am
by anjanesh
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.
Posted: Wed Aug 03, 2005 12:20 pm
by josh
anjanesh 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.
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 ask
Posted: Wed Aug 03, 2005 12:23 pm
by nielsene
if you had to, extend your database schema, store an epoch and a timestamp. Epoch would default to 0. For dates past the roll over, increment to 1. You'll have to use application logic to properly compare dates (ie dates with equal timestamps but unequal epoch aren't equal)
Posted: Wed Aug 03, 2005 3:18 pm
by Roja
jshpro2 wrote:I have a question, what's going to happen when the date nears 2038, are alternative time functions in the planning?
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.
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( ).
Posted: Wed Aug 03, 2005 3:46 pm
by timvw
Roja wrote:jshpro2 wrote:I have a question, what's going to happen when the date nears 2038, are alternative time functions in the planning?
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.
It's somewhere at
http://www.derickrethans.nl/ as he's the one working on it
