On Fri, 19 Jan 2018, Matthew Donadio wrote:
On Thu, Jan 18, 2018 at 10:14 PM, Tim Parenti <tim@timtimeonline.com> wrote:
It is now 03:14 UTC on 19 January 2018. Twenty years from now, POSIX and POSIX-based timestamps, which have more-or-less been counting seconds since 1970, will reach 2^31 and thus overflow signed 32-bit integers. Since all sorts of forward-looking date arithmetic abounds, it is inevitable that there are still active applications that will mishandle this. Twenty years out is an interesting point when more of those seams might start to show, and left unpatched, that would only increase as we approach 2038. It's much like Y2K, but in binary… and with seconds.
So keep your eyes peeled in the near future for anything suddenly thinking it'll somehow be December 1901 in the slightly-more-distant future. You have some insight into just why that'll be happening.
Something to keep in mind with this is that even if you are on a 64-bit architecture, these are some instances where you may be working with 32-bit timestamps. I know some PHP builds for Windows are like this (the builds are actually 32-bit).
That's not true. On a 64-bit platform, you should run a 64-bit build Windows. The problem on Windows was that its "long" is an int32_t, but this all got resolved with PHP 7.0 (out for 2+ years), where it now uses an int64_t-like type. If you'd been using the DateTime class-based APIs (new in PHP 5.2, 11+ years old), then it would have wrapped a 64-bit int already, and not have a problem with this. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug