Re: Y2038 BUG

Bryan Green <dbryan.green@gmail.com> writes:
> There is a Y2038 bug in win32gettimeofday.c due to long being 32-bits on
> Windows and the use of struct timeval.

Yeah.

>  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?

I'm not sure how much we can do about this without knowing what they
and other platforms will do.  The one saving grace about this is that
we don't need a huge amount of advance notice, because we don't use
time_t and friends for any future timestamps, only current time.

> If we choose to create our own timeval struct, should we convert to
> struct timespec instead?

The bigger picture here is that POSIX defines both struct timeval
and struct timespec as using time_t, so on a platform that hasn't
widened time_t there is going to be a Y2038 issue no matter what.
struct timespec isn't going to help.

The last I heard about this (which was some time ago now) there
was some thought among libc maintainers that they might not take
the ABI break of widening time_t on 32-bit platforms, but instead
redefine the origin (time_t zero) every 70 years or so.  That would
actually be rather problematic for us because we need to know the
origin in order to convert clock readings into PG timestamps.

It would likely be a good idea to take steps to remove direct
dependence on time_t/timeval/timespec from as many places as possible,
so as to minimize the blast radius once platforms start to actually
deal with this issue.

It looks like we've allowed a lot of frontend code to avoid the
backend practice of working in Timestamp(Tz).  Maybe that's okay ---
assuming that that code is only interested in times near current
time --- but it's certainly something that could bite people on the
rear if they're careless about assumptions.

            regards, tom lane