SitePoint Sponsor

User Tag List

Results 1 to 15 of 15
  1. #1
    SitePoint Wizard wheeler's Avatar
    Join Date
    Mar 2006
    Location
    Gold Coast, Australia
    Posts
    1,369
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question 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.

    So the question is, can I rely on epoch?

    EDIT: Can't help but add this quote from wikipedia in on http://en.wikipedia.org/wiki/Year_2038_problem -
    Using a (signed) 64-bit value introduces a new wraparound date in about 290 billion years, on Sunday, December 4, 292,277,026,596. However, this is not widely regarded as a pressing issue.
    Last edited by wheeler; May 6, 2007 at 22:06.
    Studiotime - Time Management for Web Developers
    to-do's, messages, invoicing, reporting - 30 day free trial!
    Thomas Multimedia Web Development

  2. #2
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,578
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    SitePoint Wizard wheeler's Avatar
    Join Date
    Mar 2006
    Location
    Gold Coast, Australia
    Posts
    1,369
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    good point, probably a bit pointless thinking about it in this case. Is there anything comparable to unix timestamp in the way that time difference can be calculated?
    Studiotime - Time Management for Web Developers
    to-do's, messages, invoicing, reporting - 30 day free trial!
    Thomas Multimedia Web Development

  4. #4
    SitePoint Wizard HarryR's Avatar
    Join Date
    Dec 2004
    Location
    London, UK
    Posts
    1,376
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  5. #5
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    368
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thats 30 years from now, which is a long time in internet years

    think how old the internet is and how old php itself is

    dont worry about it and you only gonna end up storing more data than needed

  6. #6
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,578
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wheeler View Post
    Is there anything comparable to unix timestamp in the way that time difference can be calculated?
    DATE_SUB()/DATE_ADD()
    http://dev.mysql.com/doc/refman/5.0/...functions.html

  7. #7
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dan Grossman View Post
    It's hard to imagine a PHP5 app will be running in 2037 (or whatever year you'd start seeing bookings in 2038).
    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.

  8. #8
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    368
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well fisrtly we are taling about the database not php

    (you would be a bigger fool in writting a critical app that you expect to work for decades in php)



    anyways come to 2036 and for some reason you are still running php5 and mysql4-5 how hard would it be to loop thru the dataset and add extra 10 zeros to the front of every timestamp?



    more than likely by that time google will make sure all your data belongs to them



    as for php itself i wonder will they have threading, namespaces and proper unicode support by 2036? development lately seems to be at glacial speed
    Last edited by mihd; May 7, 2007 at 02:25.

  9. #9
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,578
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog View Post
    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.

  10. #10
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The problem OP was talking about is not php specific. Code that uses "unix timestamps" instead of dedicated datetime type is myopic at best, no matter how long the application is going to be used.

  11. #11
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,578
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    The range of a UNIX timestamp is 1970 to infinity. It's only limited by how many bytes we use to store it. If we allocate more bytes, we increase its range. There's the non-PHP-specific answer

  12. #12
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You cannot just come and allocate more bytes to the timestamp. If OS uses 32 bit time_t, that will still be the case for the next 3-4 years, there's nothing you can do about it.

  13. #13
    SitePoint Enthusiast
    Join Date
    Apr 2007
    Posts
    63
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  14. #14
    SitePoint Wizard wheeler's Avatar
    Join Date
    Mar 2006
    Location
    Gold Coast, Australia
    Posts
    1,369
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    good stuff, well no point speculating on where the internet will be in 30 years time, although I do suspect that real progress will slow as the novelty wears off completely.

    I can see some existing clients the type who might get something they like, and upgrade about as often as Halley's Comet swings past Earth.

    Good to see there is a mysql alternative, although it looks as though some of those functions require mysql 4.1+ which could be an issue if my work is to be widely compatible.

    Looks like unix timestamp is still the most practical for at least calculating time differences, mysql is making headway but only in more recent versions.
    Studiotime - Time Management for Web Developers
    to-do's, messages, invoicing, reporting - 30 day free trial!
    Thomas Multimedia Web Development

  15. #15
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •