Re: recommending AC_SYS_YEAR2038_REQUIRED ?

[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