[tz] The Y2038 problem is 20 years away

Derick Rethans 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 mailing list