time() and friends have Y2038 problem on 64 Windows

[cmb69]

Description

I travelled 15 years into the future, and run the following code:

<?php
var_dump(time());

Resulted in this output:

int(-2081770632)

But I expected this output instead:

int(2213196664)

The problem is

php-src/win32/time.c

Line 46 in 3d9a0a0

tv->tv_sec = (long)(ff / 1000000Ui64);

Casting to long is appropriate since the declaration of struct timeval in WinSock2.h is:

struct timeval {
        long    tv_sec;         /* seconds */
        long    tv_usec;        /* and microseconds */
};

However, long is a 32bit value on LLP64 architectures.

One may argue that time travel is not supportable, but maybe we should heed the POSIX 7 advise:

Applications should use the clock_gettime() function instead of the obsolescent gettimeofday() function.

gettimeofday() has been removed from POSIX 8 altogether.

PHP Version

any

Operating System

Windows

[nielsdos]

A bit related to #14141

[cmb69]

Wow, serious mess here. While we're checking for the availability of gettimeofday() during configuration, setting HAVE_GETTIMEOFDAY if so, in a couple of places we just call the function even though it might not be available. Sometimes we check whether the gettimeofday() call failed, and sometimes we just assume it cannot fail. As fallback we're using time(), but still prefer gettimeofday() even when we don't use the microseconds.

And those calls to gettimeofday() are spread all over the place.

[cmb69]

Oh, forgeot: instead of using clock_gettime() we can likely use timespec_get() which is a C11 function.