time() and friends have Y2038 problem on 64 Windows

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

https://github.com/php/php-src/blob/3d9a0a0c17c1660116c0699e6be734817d616292/win32/time.c#L46

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

Start in win32/time.c around the linked line where time() obtains and casts tv_sec, then review the Windows LLP64 limitation described in the report and the related time APIs. Confirm the behavior on 64-bit Windows and define completion as returning a correct positive timestamp beyond 2038 without the current 32-bit overflow.