Re: recommending AC_SYS_YEAR2038_REQUIRED ?

From: Paul Eggert <eggert@cs.ucla.edu>
To: "Zack Weinberg" <zack@owlfolio.org>,
	"Pádraig Brady" <P@draigBrady.com>,
	"Bruno Haible" <bruno@clisp.org>,
	bug-gnulib@gnu.org
Cc: Sam James <sam@gentoo.org>, distributions@lists.linux.dev
Subject: Re: recommending AC_SYS_YEAR2038_REQUIRED ?
Date: Mon, 10 Apr 2023 12:52:20 -0700	[thread overview]
Message-ID: <c87cc7dd-4eb8-49a1-e27e-b5621909b617@cs.ucla.edu> (raw)
In-Reply-To: <bffe78fa-dc4d-46e5-8c2d-27f7aaa7baac@app.fastmail.com>

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