On 03.10.2021 08:49, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> W dniu 01.10.2021 o 20:27, Jakub Bogusz pisze:
> > On Fri, Oct 01, 2021 at 12:36:20PM +0200, arekm wrote:
> >> commit 0818a4328225cca2d41e43f0fa816f38bb3cbe69
> >> Author: Arkadiusz Miśkiewicz
> >> Date: Fri Oct 1 12:36:07 2021 +0200
> >>
> >> Rel 6; make sure we don't include expired certs
> >
> > Unfortunately ix86 `date` doesn't know y2038+...
> >
> > | date: invalid date 'Oct 25 08:25:55 2043 GMT'
> >
> >
>
> Jan, what was the reason behind --disable-year2038 in coreutils?
>
> Enabling that and date on ix86 parses such date correctly (with
> coreutils 9.0).
The primary effect of y2038 handling is change of time_t from 32bit to
64bit which breaks abi compatibility with external libraries that were
not compiled with y2038. If there's any library call that involves
time_t either directly (argument/return value) or indirectly (member of
publicly defined struct) then it will cause incorrect results if caller
and callee use different time_t size. That's exactly what happened in
wget interacting with libmetalink:
https://savannah.gnu.org/bugs/index.php?61140
whether any such situation is possible in coreutils -- don't know, but
to be on the safe side I prefer to disable it for the time being.
Especially that y2038 handling is still a moving target. ie even if you
don't use y2038 glibc requires you to be aware of internal mechanisms to
handle it in order to use api correctly:
https://github.com/systemd/systemd/issues/20564
I would say y2038 is either all or nothing. At some point we'd need
rebuild everything with 64bit time_t (and keep our fingers crossed that
abi breakages do not happen too often on builders during the process of
transition).
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
