> > > * If the underlying time_t is not Y2038-proof, Gnulib makes no effort > > > to fix the situation. > > > > Incorrect. I explained this in > > <https://lists.gnu.org/archive/html/bug-gnulib/2018-07/msg00041.html>. > > Maybe I misunderstood, then: for me, this explanation meant that if > the architecture *could* provide a Y2038-proof time_t but only under the > right circumstances (i.e., it provides a 32-bit time_t *or* a 64-bit > one depending on the presence or value of some -D compiler options), > then year2038 will ensure these circumstances happen (i.e., make it so > that the right -D options are passed); but if the architecture does not > in *any* circumstance provide a Y2038-proof time_t, then year2038 will > not fix *that* by pulling a magic time_t out of a hat.
Correct. Bruno
