The Y2038 problem is 20 years away
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. -- Tim Parenti
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). This can make unit testing very difficult if you can't properly test in an affected environment. --Matthew Donadio (matt@mxd120.com)
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
On Fri, Jan 19, 2018 at 9:15 AM, Derick Rethans <tz@derickrethans.nl> wrote:
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.
Should you use it? Yes, absolutely. But there are still LTS deployments that have this problem, and some common starter-kit local environments that are still bundled with 32-bit PHP. This pops up three or four times a year for me in the Drupal issue queues.
On Fri, 19 Jan 2018, Matthew Donadio wrote:
On Fri, Jan 19, 2018 at 9:15 AM, Derick Rethans <tz@derickrethans.nl> wrote:
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.
Should you use it? Yes, absolutely. But there are still LTS deployments that have this problem, and some common starter-kit local environments that are still bundled with 32-bit PHP. This pops up three or four times a year for me in the Drupal issue queues.
Even on 32-bit PHP builds, the Date/Time classes wrap a 64-bit int. 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
Matthew Donadio wrote:
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). This can make unit testing very difficult if you can't properly test in an affected environment.
I think you need to distinguish here. Specifically on Windows it doesn't make a big difference if you build a 32 bit or 64 bit executable, or if you run it on a 32 bit or 64 bit version of the Windows OS. What *does* matter, though, is the build environment used to compile an application. If you build with Visual Studio 2005 or newer, then time_t is 64 bit by default, and the related functions provided by the compiler's run-time library deal with it. VS uses 32 bit time_t only if you define a specific preprocessor symbol, or if you run a Visual Studio version older than VS2015. But of course you have to take care anyway if you work with fixed data structures that only provide 32 bit time stamps, as the integer part of the time stamps used by the NTP network packets. Such time stamps have to be expanded/converted accordingly to represent times beyond the 32 bit limit even if the build environment supports 64 bit time_t. The reference implementation of NTP takes care of this 'epoch'. So IMO you need to take care with which tools PHP has been build, and what you do with it. Martin
Matthew Donadio wrote:
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). This can make unit testing very difficult if you can't properly test in an affected environment.
I think you need to distinguish here. Specifically on Windows it doesn't make a big difference if you build a 32 bit or 64 bit executable, or if you run it on a 32 bit or 64 bit version of the Windows OS. What *does* matter, though, is the build environment used to compile an application. If you build with Visual Studio 2005 or newer, then time_t is 64 bit by default, and the related functions provided by the compiler's run-time library deal with it. VS uses 32 bit time_t only if you define a specific preprocessor symbol, or if you run a Visual Studio version older than VS2015. But of course you have to take care anyway if you work with fixed data structures that only provide 32 bit time stamps, as the integer part of the time stamps used by the NTP network packets. Such time stamps have to be expanded/converted accordingly to represent times beyond the 32 bit limit even if the build environment supports 64 bit time_t. The reference implementation of NTP takes care of this 'epoch'. So IMO you need to take care with which tools PHP has been build, and what you do with it. Martin
Is there anything more that tzcode should be doing about this looming deadline? Should we be discouraging builds on platforms with 32-bit signed time_t? Currently, zic.c and tzfile.h do the right thing even if time_t is 32 bits, and do not use time_t at all. So zic should be safe even if time_t is a signed 32-bit integer. However, all the other programs and libraries that we build generate code that will not work for timestamps after 2038, if built with 32-bit signed time_t. It wouldn't be hard to change tzcode to refuse to compile non-zic C modules on platforms with 32-bit signed time_t; is that something we should consider doing?
participants (6)
-
Derick Rethans -
Martin Burnicki -
Martin Burnicki -
Matthew Donadio -
Paul Eggert -
Tim Parenti