Yr 2038 on Linux

Questions about the MySQL, PostgreSQL, and most other databases, as well as using it with PHP can be asked here.

Moderator: General Moderators

Post Reply
User avatar
anjanesh
DevNet Resident
Posts: 1679
Joined: Sat Dec 06, 2003 9:52 pm
Location: Mumbai, India

Yr 2038 on Linux

Post 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
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post 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.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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...
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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"
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

Btw,

Code: Select all

SELECT UNIX_TIMESTAMP('2038-01-19 00:00:00');
returns 0
User avatar
anjanesh
DevNet Resident
Posts: 1679
Joined: Sat Dec 06, 2003 9:52 pm
Location: Mumbai, India

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Post 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>
User avatar
anjanesh
DevNet Resident
Posts: 1679
Joined: Sat Dec 06, 2003 9:52 pm
Location: Mumbai, India

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Post 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
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post 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)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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( ).
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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 ;)
Post Reply