Re: Y2038 BUG

On 11/2/2025 4:48 PM, Tom Lane wrote:
> 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.
> 

Microsoft now has a define for time_t that sets it to __time64_t.

In versions of Visual C++ and Microsoft C/C++ before Visual Studio 2005,
time_t was a long int (32 bits) and hence could not be used for dates
past 3:14:07 January 19, 2038, UTC. time_t is now equivalent to
__time64_t by default, but defining _USE_32BIT_TIME_T changes time_t to
__time32_t and forces many time functions to call versions that take the
32-bit time_t. For more information, see Standard types and comments in
the documentation for the individual time functions.
 ...per
https://learn.microsoft.com/en-us/cpp/c-runtime-library/time-management?view=msvc-170

timeval is still problematic on windows though...just available through
winsock2.h and uses long..not time_t.

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

I agree. I will give this some thought.

> 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

Yes, when I first saw this, I thought "oh, I can probably just handle
this with a new pg_timeval and only have to worry about
GetTimestampTZ...".

Bryan