Re: 64-bit time_t

On Tue, Jan 2, 2024 at 7:45=E2=80=AFAM Bernhard M. Wiedemann <bwiedemann@su=
se.de> wrote:
>
> In https://lore.kernel.org/distributions/6614772.670kD7asE2@nimes/
> Bruno Haible wrote:
>
> > 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 expensiv=
e,
> >   did the distro people say.
>
> or option c)
> One less troublesome solution could be to patch glibc to redefine the
> 32-bit time_t as unsigned so that ABIs could remain compatible and at
> the same time it would support timestamps until 2106.
> Though that would break any application that uses time_t for dates
> between 1901 and 1970 (are there any?).
> Do I miss any other downsides?
> This seems to be the only option that allows legacy-binaries to keep
> working after 2038.
>
>
> option d) would be to adapt all libraries that have time_t in their API
> to have both 32-bit and 64-bit time_t variants. The former for
> compatibility with old binaries and the latter for new future-proof
> binaries. This could provide a smooth transition because not all
> 3rd-party binaries can be rebuilt.
> The trouble here would be the effort for the libraries to provide 2
> variants and for callers to select the right variant.
>

In my view, Option D would be ideal, but otherwise we should probably
just break everything and do option A unless glibc has already
switched unsigned numbers for time_t in 64-bit time, so then using
32-bit time_t unsigned would be "okay" and thus Option C would work.




--
=E7=9C=9F=E5=AE=9F=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E4=B8=80=E3=81=A4=EF=
=BC=81/ Always, there's only one truth!