Re: recommending AC_SYS_YEAR2038_REQUIRED ?

[Paul Eggert]

On 2023-04-10 12:09, Zack Weinberg wrote:
> I was imagining something to do
> with library ABIs involving time_t, or network and/or storage formats
> explicitly specified to use 64-bit counts of seconds since the Unix
> epoch, or similar.

Needs are not limited to library code. Applications like 'ls' and 'date' 
and even 'grep' need support for timestamps past 2038. A 'grep' built 
with 32-bit time_t can't read files with timestamps after 2038.

Many embedded systems being developed now will still be used after 2038, 
long after their current developers have left (or fled :-) the scene. 
And some of these will be part of important infrastructure such as 
municipal water systems. For general-purpose apps like coreutils that 
are widely used in these systems, 32-bit time_t should be opt-in not 
opt-out, so that developers know of the problem and consciously decide 
to go with 32-bit time_t despite the looming 2038 deadline.

Of course there are occasions where one can still safely build for 
platforms that one *knows* won't be in use 15 years from now. So we'll 
need to describe how to do that and I plan to follow up with a Gnulib 
doc patch along those lines.

PS. Timestamp needs are more complicated than 32 vs 64 bits. For 
example, ustar format (specified by POSIX) has 33-bit unsigned 
timestamps. And gzip format (specified by RFC 1952)  has timestamps in 
the range 1 .. (2**32 - 1).