Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-19 Thread Zack Weinberg 
On Wed, Apr 19, 2023, at 5:23 PM, Paul Eggert wrote:
> On 2023-04-11 17:10, Zack Weinberg wrote:
>> I'm also happy with this resolution.  I do not have time to do the Autoconf 
>> work until the weekend.
>
> I notice you were careful to not say *which* weekend. :-)

Ugh. Yeah. Don't expect anything out of me before the end of CMU's spring term 
(second week of May) at the absolute earliest.

zw

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-19 Thread Paul Eggert 

On 2023-04-11 17:10, Zack Weinberg wrote:

I'm also happy with this resolution.  I do not have time to do the Autoconf 
work until the weekend.


I notice you were careful to not say *which* weekend. :-)

Anyway, I coded up a draft patch and published it here:

https://lists.gnu.org/r/autoconf/2023-04/msg00027.html

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-11 Thread Sam James 

Bruno Haible  writes:

> Paul Eggert wrote:
>> > How about a middle ground between the two macros? A macro, say
>> > AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that
>> >- like AC_SYS_YEAR2038, has the option --disable-year2038,
>> >- like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is
>> >  unavailable and --disable-year2038 was not specified.
>> 
>> Even simpler, let's have just one new macro instead of two. I.e., let's 
>> change Autoconf to remove AC_SYS_YEAR2038_REQUIRED and to define instead 
>> a macro AC_SYS_YEAR2038_OPT_OUT that acts like AC_SYS_YEAR2038 except it 
>> errors out if wide time_t and --disable-year2038 are both missing.
>> 
>> Then let's propagate this change into Gnulib, and rename Gnulib's 
>> year2030-required module to year2038-opt-out.
>
> I like this. Thanks.

Thanks for bringing this up Bruno. This is a reasonable compromise to me
- not just in the change here, but in the documentation/phrasing tweak
as I was concerned about the rather forthright recommendation & presentation of
year2038-required.

>
> And if the package would very much like to assume a wide time_t and
> therefore has some test suite failures if --disable-year2038 was specified,
> so be it. It's better to be able to build a package at all, with some
> test suite failures, than not being able to build it at all.
>

I feel on the fence about this bit: I think it's reasonable to provide
a macro to require it as a last resort for people, but on the other
hand, providing it might be seen to encourage it as a reasonable
solution, when in most cases, it's not that way at all,
so I'll go with however the majority feels on that.

>> Similarly for AC_SYS_LARGEFILE_REQUIRED.

... and this.

>
> For the sake of symmetry between the two, that makes sense.
>

Thanks Paul as well.

best,
sam


signature.asc
Description: PGP signature

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-11 Thread Zack Weinberg 
On Mon, Apr 10, 2023, at 7:00 PM, Paul Eggert wrote:
> On 2023-04-10 15:36, Bruno Haible wrote:
>> I like this. Thanks.
>
> OK, then let's hear Zack's opinion and hopefully move forward.

I'm also happy with this resolution.  I do not have time to do the Autoconf 
work until the weekend.

zw

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Paul Eggert 

On 2023-04-10 15:36, Bruno Haible wrote:

I like this. Thanks.


OK, then let's hear Zack's opinion and hopefully move forward.

In the meantime I installed the attached Gnulib patch, which documents 
the current situation better as you suggested (e.g., by suggesting 
year2038 first) and updates some of the version info.From 3e6b572b5f6dcd204f3636e3c7a265063a315f2c Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 10 Apr 2023 15:15:37 -0700
Subject: [PATCH 1/3] doc: document year2038 first

* doc/year2038.texi: Document year2038 first, then
year2038-required.
---
 doc/posix-headers/time.texi |  2 +-
 doc/year2038.texi   | 59 +
 2 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/doc/posix-headers/time.texi b/doc/posix-headers/time.texi
index f9d1def2aa..70814d6cda 100644
--- a/doc/posix-headers/time.texi
+++ b/doc/posix-headers/time.texi
@@ -19,7 +19,7 @@ NetBSD 5.0.
 @end itemize
 
 Portability problems fixed by the Gnulib module
-@code{year2038-required} or @code{year2038}:
+@code{year2038} or @code{year2038-required}:
 @itemize
 @item
 On some platforms where @code{time_t} defaults to 32-bit but can be
diff --git a/doc/year2038.texi b/doc/year2038.texi
index cae738c5da..81b212e455 100644
--- a/doc/year2038.texi
+++ b/doc/year2038.texi
@@ -8,15 +8,39 @@ after 2038-01-19 03:14:08 UTC@.  See
 @url{https://en.wikipedia.org/wiki/Year_2038_problem, Year 2038
 problem} for details.
 
-The Gnulib module @samp{year2038-required} fixes this problem, by
-making @code{time_t} wide enough to represent timestamps after 2038.
-This has no effect on most current systems, which have timestamps that
-are already wide enough.  However, @samp{year2038-required} arranges
-for builds on legacy 32-bit x86 and ARM Linux kernels running glibc
-2.34 and later to compile with @samp{_TIME_BITS=64} to get wider
+The Gnulib module @samp{year2038} fixes this problem on some
+platforms, by making @code{time_t} wide enough to represent timestamps
+after 2038.  This has no effect on most current platforms, which have
+timestamps that are already wide enough.  However, @samp{year2038} by
+default arranges for builds on legacy 32-bit Linux kernels running
+glibc 2.34 and later to compile with @samp{_TIME_BITS=64} to get wider
 timestamps.  On older platforms that do not support timestamps after
-the year 2038, @samp{year2038-required} causes @command{configure} to
-fail.
+the year 2038, @samp{year2038} causes @command{configure} to issue a
+warning but still proceed.  On platforms that appear to support
+post-2038 timestamps but where something prevents this from working,
+@command{configure} fails.
+
+The default behavior of @samp{year2038} can be overridden by using the
+@command{configure} option @option{--disable-year2038}, which
+suppresses support for post-2038 timestamps.  This may be useful if
+the package links to other libraries whose user-facing ABIs still
+require @code{time_t} to be 32-bit on your platform.
+
+The Gnulib module @samp{year2038-required} is like @samp{year2038},
+except it rejects platforms where @code{time_t} cannot represent
+timestamps after 2038, and it lacks a @option{--disable-year2038}
+option.  If this module is used and a 32-platform cannot support
+64-bit @code{time_t}, one can still fix the year-2038 problem by using
+a 64-bit instead of a 32-bit build, as noted in the architecture list
+below.  If all else fails one can configure with
+@samp{ac_year2038_required=no}; however, the resulting programs will
+mishandle timestamps after 2038.
+
+The Gnulib module @samp{year2038-required} is
+recommended for packages intended for use on 32-bit platforms
+after the year 2038.  However, if your package needs to support
+32-bit platforms that will not be used after the year 2038,
+you can use the @samp{year2038} module instead.
 
 With the @samp{year2038-required} module, @command{configure} fails
 on the following 32-bit platforms (or ABIs in bi-arch systems):
@@ -65,26 +89,11 @@ FreeBSD/arm,
 Minix 3.3.
 @end itemize
 
-The Gnulib module @samp{year2038} is like @samp{year2038-required},
-except that it causes @command{configure} to fail only when it appears
-that the current system should support post-2038 timestamps but
-something prevents that from working.  Also, @samp{year2038} gives
-@command{configure} a @option{--disable-year2038} option, which
-suppresses support for post-2038 timestamps.  This may be useful if
-the package links to other libraries whose user-facing ABIs still
-require @code{time_t} to be 32-bit on your platform.
-
-The Gnulib module @samp{year2038-required} is
-recommended for any package that might be used after the year 2038 on
-32-bit platforms.  However, if your package needs to support
-platforms that will not be used after the year 2038,
-you can use the @samp{year2038} module instead.
-
 If the Gnulib module @samp{largefile} is used but neither
 @samp{year2038} nor @samp{year2038-required} is used,

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Bruno Haible 
Paul Eggert wrote:
> > How about a middle ground between the two macros? A macro, say
> > AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that
> >- like AC_SYS_YEAR2038, has the option --disable-year2038,
> >- like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is
> >  unavailable and --disable-year2038 was not specified.
> 
> Even simpler, let's have just one new macro instead of two. I.e., let's 
> change Autoconf to remove AC_SYS_YEAR2038_REQUIRED and to define instead 
> a macro AC_SYS_YEAR2038_OPT_OUT that acts like AC_SYS_YEAR2038 except it 
> errors out if wide time_t and --disable-year2038 are both missing.
> 
> Then let's propagate this change into Gnulib, and rename Gnulib's 
> year2030-required module to year2038-opt-out.

I like this. Thanks.

And if the package would very much like to assume a wide time_t and
therefore has some test suite failures if --disable-year2038 was specified,
so be it. It's better to be able to build a package at all, with some
test suite failures, than not being able to build it at all.

> Similarly for AC_SYS_LARGEFILE_REQUIRED.

For the sake of symmetry between the two, that makes sense.

Bruno

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Paul Eggert 

On 2023-04-10 14:08, Bruno Haible wrote:

Applications like 'ls' and 'date'
and even 'grep' need support for timestamps past 2038.

... if they are used in hardware that will operate in and beyond 2038.


That's not the only reason year-2038 support is needed. And it's not 
just trivial things like "date -d'now + 15 years'"; it's packages like 
tar and coreutils that need to work even in environments where users 
today can mistakenly (or purposely!) set file timestamps to be 15 years 
from now. A common command like 'grep' or 'find' shouldn't misbehave 
merely because a file timestamp is in the future.


I plan to reword the manual to suggest year2038 over year2038-required 
as you suggested, and to give packagers an out even when 
year2038-required is used. However, for core packages year 2038 support 
really should be opt-out, not opt-in, and for these packages 
year2038-required is more likely to save people trouble down the road.


If we change to AC_YEAR2038_OPT_OUT we can update the manual accordingly 
of course.

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Paul Eggert 

On 2023-04-10 14:42, Bruno Haible wrote:

How about a middle ground between the two macros? A macro, say
AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that
   - like AC_SYS_YEAR2038, has the option --disable-year2038,
   - like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is
 unavailable and --disable-year2038 was not specified.


Even simpler, let's have just one new macro instead of two. I.e., let's 
change Autoconf to remove AC_SYS_YEAR2038_REQUIRED and to define instead 
a macro AC_SYS_YEAR2038_OPT_OUT that acts like AC_SYS_YEAR2038 except it 
errors out if wide time_t and --disable-year2038 are both missing.


Then let's propagate this change into Gnulib, and rename Gnulib's 
year2030-required module to year2038-opt-out.


Similarly for AC_SYS_LARGEFILE_REQUIRED.

Since this is a change to Autoconf I'd like to hear Zack's opinion.

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Bruno Haible 
Paul,

Here's a suggestion for a compromise.

Recall that the macro AC_SYS_YEAR2038_REQUIRED is like AC_SYS_YEAR2038,
with two modifications:
  - It causes configure to fail if a large 'time_t' is unavailable,
  - It removes the configure option --disable-year2038.

How about a middle ground between the two macros? A macro, say
AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that
  - like AC_SYS_YEAR2038, has the option --disable-year2038,
  - like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is
unavailable and --disable-year2038 was not specified.

It would force the packager to pass --disable-year2038 if he
accepts the year-2038 problems.

It would not require additional documentation.

That would be OK with me.

Would it be OK with you?

Bruno

(*) Feel free to find a better name.

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Bruno Haible 
Hi Paul,

I want to avoid year-2038 breakage as much as you want. But what you
are doing in coreutils and recommending through the Gnulib manual
goes beyond that goal.

> Applications like 'ls' and 'date' 
> and even 'grep' need support for timestamps past 2038.

... if they are used in hardware that will operate in and beyond 2038.

Please read again my concerns regarding distro people and users/sysadmins.

I am sysadmin of a machine with an Intel 'Atom' CPU (x86) and want the
freedom to install, up until December 2037, any new releases of software
on it. What you have done in coreutils is to prevent me from installing
coreutils 9.3 or newer.

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

It is their responsibility — of the people who assemble such municipal
water systems — to do so, not yours as maintainer of any particular
package that gets installed on this system.

The proper actions to achieve the goal would be to
  - raise awareness of the problem,
  - get active in the organizations of the people who assemble such
systems, to exert influence there.

You are trying to exert influence / power on *everyone* who installs
coreutils, and as I've described in the previous mail, this has
negative effects on some distro guys and some users.

> For general-purpose apps like coreutils that 
> are widely used in these systems, 32-bit time_t should be opt-in not 
> opt-out

But the 'year2038' module / the AC_SYS_YEAR2038 is already opt-in,
not opt-out. It offers an option --disable-year2038.

> so that developers know of the problem and consciously decide 
> to go with 32-bit time_t despite the looming 2038 deadline.

Please by all means, increase awareness. But choosing
AC_SYS_YEAR2038_REQUIRED instead of AC_SYS_YEAR2038, and thus
suppressing the --disable-year2038 configure option, is more
than let packagers / users "consciously decide". You are not
giving them any decision power, since you have removed that
decision power from them already.

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

The Gnulib documentation is the wrong place to explain such a
workaround or option. It needs to be explained in the 'configure --help'
output of the package.

Bruno

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread 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).

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Bruno Haible 
Zack Weinberg wrote:
> As the person who invented AC_SYS_YEAR2038_REQUIRED and
> AC_SYS_LARGEFILE_REQUIRED, let me say that it was my intention that they
> would only be used in rare circumstances, where the inability to install
> the software on older ABIs is outweighed by some other strong
> requirement for time_t and/or off_t to be at least 64 bits.  I didn't
> have any specific use cases in mind but 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.

Thanks for the clarification.

Note that I'm perfectly fine with AC_SYS_LARGEFILE_REQUIRED being
documented, because
  - it makes perfect sense for packages that regularly deal with files
larger than 2 GiB, such as video manipulation,
  - hardly any platform nowadays lacks a way to enforce large files in
the API.

Bruno

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Zack Weinberg 
On Mon, Apr 10, 2023, at 10:12 AM, Pádraig Brady wrote:
> On 10/04/2023 14:40, Bruno Haible wrote:
>> Hi Paul, In yesterday's changes, you added to the Gnulib
>> documentation, section "Avoiding the year 2038 problem", wording that
>>
>>* explicitly recommends the ‘year2038-required’ module, which does
>>  AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]):
...
>> I strongly object to this recommendation and presentation.
...
>> It is simply the wrong person's decision if the package maintainer
>> uses the AC_SYS_YEAR2038_REQUIRED macro.
...
>> When AC_SYS_YEAR2038_REQUIRED is used, the package can no longer be
>> installed on the following 32-bit platforms/ABIs:
...
>> I would therefore propose that the module 'year2038-required' gets
>> removed from Gnulib, as I cannot see any positive uses of it.

As the person who invented AC_SYS_YEAR2038_REQUIRED and
AC_SYS_LARGEFILE_REQUIRED, let me say that it was my intention that they
would only be used in rare circumstances, where the inability to install
the software on older ABIs is outweighed by some other strong
requirement for time_t and/or off_t to be at least 64 bits.  I didn't
have any specific use cases in mind but 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.

zw

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Pádraig Brady 

On 10/04/2023 14:40, Bruno Haible wrote:

Hi Paul,

In yesterday's changes, you added to the Gnulib documentation, section
"Avoiding the year 2038 problem", wording that

   * explicitly recommends the ‘year2038-required’ module,
 which does AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]):

 "The Gnulib module ‘year2038-required’ is recommended for any package
  that might be used after the year 2038 on 32-bit platforms."

   * presents the ‘year2038-required’ module as the first and the ‘year2038’
 module (which does AC_REQUIRE([AC_SYS_YEAR2038])) only as the secondary
 option.

I strongly object to this recommendation and presentation.

The reason is that we have three personas:
   - The package maintainer who edits configure.ac.
   - The distro people who create distros comprised of many packages,
 passing appropriate options to 'configure'.
   - The user / sysadmin who installs packages on their systems from source,
 passing appropriate options to 'configure' as well.

If the package maintainer adds an AC_SYS_YEAR2038_REQUIRED invocation to
his package's configure script, or equivalently, if he pulls in the
'year2038-required' module, he is *taking freedom away* from *both* the
distro people and the users/sysadmins.

It is simply the wrong person's decision if the package maintainer
uses the AC_SYS_YEAR2038_REQUIRED macro.

In detail:

When AC_SYS_YEAR2038_REQUIRED is used, the package can no longer be
installed on the following 32-bit platforms/ABIs:

   - Linux with glibc < 2.34 on x86, arm, mips (32-bit or n32 ABI), powerpc,
 sparc, s390, hppa, m68k, sh, csky, microblaze, nios2,
   - Linux/riscv32,
   - Mac OS X on x86 and powerpc,
   - GNU/Hurd/x86,
   - GNU/kFreeBSD/x86,
   - FreeBSD/x86,
   - MidnightBSD/x86,
   - AIX/powerpc,
   - Solaris 10 and 11 on x86 and sparc,
   - Cygwin/x86,
   - Haiku/x86.

Regarding the distro people:

   The outcome of a discussion, about a month or two ago, was AFAIU that
   Linux/x86 and Linux/arm distros have a choice between
 (a) enabling 64-bit time_t for all packages, thus breaking ABI
 compatibility once and becoming year 2038 saft, or
 (b) staying with the 32-bit time_t, and announcing that their
 distro will stop working in 2038.
   An incremental or partial move to 64-bit time_t would be too expensive,
   did the distro people say.

   Now, if a package maintainer adds AC_SYS_YEAR2038_REQUIRED to their
   configure.ac, they are telling the distros of type (b) "you cannot use
   new releases of my package any more".

   This is discriminatory and without justification, since the maintainers
   of a type (b) distro already know that they have to limit the lifetime
   expectations of their distro.

Regarding the users/sysadmins:

   It is their decision to know until when they want to use their hardware,
   and which ABI they want to use for the binaries that they install on
   this hardware.

   Now, if a package maintainer adds AC_SYS_YEAR2038_REQUIRED to their
   configure.ac, they are telling the users "you cannot install releases
   of my package any more" or "I force you to install 64-bit binaries
   instead of 32-bit binaries".

   It is just not appropriate for the package maintainer to push such a
   decision onto the user.

I would therefore propose that the module 'year2038-required' gets
removed from Gnulib, as I cannot see any positive uses of it.

If that is not possible, then at least:
   1) The Gnulib documentation should present 'year2038' first, and
  'year2038-required' as a rarely needed alternative,
   2) The Gnulib documentation should not recommend 'year2038-required'.

Note: In constrast, there is nothing wrong with the Autoconf documentation.
It presents the AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED macros
without favouring one or the other.


Yes I'm a bit confused with the new restrictions myself.
A build on Solaris 10 on sparc for example now fails.
I was able to get a build to complete though by passing this to configure:

  ac_year2038_required=no

I'm confused also about the auto detection / rejection modes for this.
IIUC, previously a build would fail only if `touch -t` could create 64 bit 
times,
while the build was setup for 32 bit time_t. But now the build fails
irrespective of what touch supports. For completeness touch on this platform
does not support 64 bit times.

  > touch -t 203901010101 file.t
  touch: bad time specification

  > touch -t 203701010101 file.t

  > src/touch -t 203901010101 file.t
  touch: invalid date format '203901010101'

  > src/touch -t 203701010101 file.t

cheers,
Pádraig

recommending AC_SYS_YEAR2038_REQUIRED ?

2023-04-10 Thread Bruno Haible 
Hi Paul,

In yesterday's changes, you added to the Gnulib documentation, section
"Avoiding the year 2038 problem", wording that

  * explicitly recommends the ‘year2038-required’ module,
which does AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]):

"The Gnulib module ‘year2038-required’ is recommended for any package
 that might be used after the year 2038 on 32-bit platforms."

  * presents the ‘year2038-required’ module as the first and the ‘year2038’
module (which does AC_REQUIRE([AC_SYS_YEAR2038])) only as the secondary
option.

I strongly object to this recommendation and presentation.

The reason is that we have three personas:
  - The package maintainer who edits configure.ac.
  - The distro people who create distros comprised of many packages,
passing appropriate options to 'configure'.
  - The user / sysadmin who installs packages on their systems from source,
passing appropriate options to 'configure' as well.

If the package maintainer adds an AC_SYS_YEAR2038_REQUIRED invocation to
his package's configure script, or equivalently, if he pulls in the
'year2038-required' module, he is *taking freedom away* from *both* the
distro people and the users/sysadmins.

It is simply the wrong person's decision if the package maintainer
uses the AC_SYS_YEAR2038_REQUIRED macro.

In detail:

When AC_SYS_YEAR2038_REQUIRED is used, the package can no longer be
installed on the following 32-bit platforms/ABIs:

  - Linux with glibc < 2.34 on x86, arm, mips (32-bit or n32 ABI), powerpc,
sparc, s390, hppa, m68k, sh, csky, microblaze, nios2,
  - Linux/riscv32,
  - Mac OS X on x86 and powerpc,
  - GNU/Hurd/x86,
  - GNU/kFreeBSD/x86,
  - FreeBSD/x86,
  - MidnightBSD/x86,
  - AIX/powerpc,
  - Solaris 10 and 11 on x86 and sparc,
  - Cygwin/x86,
  - Haiku/x86.

Regarding the distro people:

  The outcome of a discussion, about a month or two ago, was AFAIU that
  Linux/x86 and Linux/arm distros have a choice between
(a) enabling 64-bit time_t for all packages, thus breaking ABI
compatibility once and becoming year 2038 saft, or
(b) staying with the 32-bit time_t, and announcing that their
distro will stop working in 2038.
  An incremental or partial move to 64-bit time_t would be too expensive,
  did the distro people say.

  Now, if a package maintainer adds AC_SYS_YEAR2038_REQUIRED to their
  configure.ac, they are telling the distros of type (b) "you cannot use
  new releases of my package any more".

  This is discriminatory and without justification, since the maintainers
  of a type (b) distro already know that they have to limit the lifetime
  expectations of their distro.

Regarding the users/sysadmins:

  It is their decision to know until when they want to use their hardware,
  and which ABI they want to use for the binaries that they install on
  this hardware.

  Now, if a package maintainer adds AC_SYS_YEAR2038_REQUIRED to their
  configure.ac, they are telling the users "you cannot install releases
  of my package any more" or "I force you to install 64-bit binaries
  instead of 32-bit binaries".

  It is just not appropriate for the package maintainer to push such a
  decision onto the user.

I would therefore propose that the module 'year2038-required' gets
removed from Gnulib, as I cannot see any positive uses of it.

If that is not possible, then at least:
  1) The Gnulib documentation should present 'year2038' first, and
 'year2038-required' as a rarely needed alternative,
  2) The Gnulib documentation should not recommend 'year2038-required'.

Note: In constrast, there is nothing wrong with the Autoconf documentation.
It presents the AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED macros
without favouring one or the other.

Bruno