[tz] The Y2038 problem is 20 years away

[Martin Burnicki]

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