[tz] The Y2038 problem is 20 years away
tz at derickrethans.nl
Fri Jan 19 14:15:55 UTC 2018
On Fri, 19 Jan 2018, Matthew Donadio wrote:
> On Thu, Jan 18, 2018 at 10:14 PM, Tim Parenti <tim at 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.
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
More information about the tz