The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Future-proofing a unix timestamp dependant php app

I'm working on a couple of apps right now that seem to be dependant on the unix epoch timestamp, that of course has a range of 1970 - 2038. I'm not expecting immediate problems but it would be nice to think that my apps are not limited to this timeframe (i'm only young!), and I don't really like the idea of a future upgrade that involves converting to a different timestamp.

So my current idea is storing timestamps in MySQL as DATETIME, but when I jump into php, it seems that I cannot avoid converting to epoch. In this case, its a booking system and so I need alot of functions around X + Y hours, X + Y Days, etc.

I know that mysql has some handy functions available for DATETIME, but to be honest this is my first use of the field type so i'm not familar with much about it.

And lastly, I presume that by 2038, the whole 32 bit limitations will be a distant nightmare for us old farts, and so perhaps I should just stick with epoch in the hope that its limitations will disappear in the not too distant future.

It's hard to imagine a PHP5 app will be running in 2037 (or whatever year you'd start seeing bookings in 2038). If somehow there is still a PHP interpreter that can read PHP5 apps in 30 years, it'll probably have updated its time functions to handle this. Your code wouldn't have to change.

On second thought, no, way too unlikely. Not only would PHP have to still be around, but HTML4/XHTML1, browsers to render it in, HTTP/1.1 web servers, cookies.. all these would have to exist to use your app. No way will they still be here in 30 years.

As others have said, it's highly unlikely that you'll have a PHP 4/5 application running in 2037, however by then the standard integer size will be atleast 64bits or above, which means your dates will be ok for another couple of thousand millenia.

That's exactly what COBOL programmers said in 60s: our program won't be running till 2000, so let's pack years into two digits.

Sure, but that's not a good comparison. PHP isn't compiled; it needs not only the computers to run it still around, but the interpreter, web servers, protocols, HTML, bowsers, RDBMS's to *all* still be around to keep using this app. It's too diverse an ecosystem PHP is reliant on to all survive the next 30 years. C might, C++ maybe, even COBOL could survive another 30, but not PHP.

And the point Dan in trying to get through, Mr. Frog, is that by 2037 you would no longer be using 32 bit OS. The bytes allocated for time would no longer be mere 4 bytes thus extending the range of timestamp.

I think the issue has nothing to do with the future of internet or similar. It may be irrelevant for your current project, but there's a wide class of today's applications that deal with dates beyond 2038 (or prior to 1901). You don't have to wait till 2037 to stumble upon "Y038" problem.