Andrew Dunstan <and...@dunslane.net> writes: > On 11/18/20 9:44 AM, Tom Lane wrote: >> Hmm. Digging around, I see that Mkvcbuild.pm intentionally absorbs >> _USE_32BIT_TIME_T when building with a Perl that defines that. >> I don't know what the state of play is in terms of Windows Perl >> distributions getting off of that, but maybe we should press people >> to not be using such Perl builds.
> I think there's a good argument to ban it if we're doing a 64 bit build > (and why would we do anything else?) I'm not really eager to ban it. If somebody is building with an old Perl distribution, and doesn't particularly care that the installation will break in 2038, why should we force them to care? What I had in mind was more along the lines of making sure that popular PG-on-Windows installers (EDB for instance) are not still using 32-bit-time_t Perl. BTW, just to clarify: AFAIK we *only* use the platform's time_t for the result of time(2) and calculations involving relatively small offsets from that, such as timeout expiration points. All our stored data has been Y2038-safe since we got rid of the abstime type. Thus, I pretty much reject the OP's position that this is something people really need to worry about years in advance. By the time it breaks for real, everything else on the platform will be broken too, unless the platform has done something about redefining time_t. regards, tom lane