Y2038 BUG

Hello,

There is a Y2038 bug in win32gettimeofday.c due to long being 32-bits on
Windows and the use of struct timeval.

int
gettimeofday(struct timeval *tp, void *tzp)

struct timeval is defined in winsock2.h and is needed by the Windows
select() call. The 64-bit values have to be narrowed to 32-bit values
for the struct timeval slots.

tp->tv_sec = (long) ((ularge.QuadPart - epoch) / FILETIME_UNITS_PER_SEC);

tp->tv_usec = (long) (((ularge.QuadPart - epoch) %
FILETIME_UNITS_PER_SEC) / FILETIME_UNITS_PER_USEC);

I set my system clock to be in 2038 you can see the "wrap-around" error
in the following test.

C:\pg99>date 01-19-2038

C:\pg99>bin\psql -d postgres -p 5454 -c "SELECT clock_timestamp(),
extract(epoch from clock_timestamp()), timeofday();"
clock_timestamp | extract | timeofday
-------------------------------+--------------------+-------------------------------------
1901-12-13 18:46:42.483928-06 | -2147469197.516072 | Fri Dec 13
18:46:42.484319 1901 CST
(1 row)

I then set it to a date before 2038 but still in the future and it
worked as expected.

C:\pg99>date 05-19-2035

C:\pg99>bin\psql -d postgres -p 5454 -c "SELECT clock_timestamp(),
extract(epoch from clock_timestamp()), timeofday();"
clock_timestamp | extract | timeofday
-------------------------------+-------------------+-------------------------------------
2035-05-19 02:15:09.119002-05 | 2063171709.119002 | Sat May 19
02:15:09.119315 2035 CDT
(1 row)

The struct timeval is unguarded in winsock2.h are we could just use the
guard to define our own.

We can create our own pg_timeval with a few helper conversion functions.
Obviously, there are a lot of places in the codebase where gettimeofday
is called. My question is whether we want to fix this now or wait with
crossed fingers that Microsoft fixes this in a timely manner?

If we choose to create our own timeval struct, should we convert to
struct timespec instead? If we want to move forward with either of
these for a Y2038 fix, I will be more than happy to create a patch for
whichever.

Bryan Green