Hi Paul, Thanks for the pointers.
> Simon Josefsson proposed something along these lines a decade ago: > > https://lists.gnu.org/archive/html/bug-gnulib/2007-03/msg00106.html > > The project is somewhat more urgent now than it was back then. I tend to agree by now. Linux/x86 will be occupying a niche market (maybe 1%) in 20 years; but if only 1% of electronic devices stop working in 2038, it would be a major mess. And you can expect that some devices that are being sold today will still be in use in 21 years: my last washing machine operated for 24 years. > > - windows-year2038 : define time_t as 64-bit (might involve renaming module > > time to time-h) > > Such a module could be useful on non-MS-Windows platforms too. The > module could support functions like localtime even on 32-bit platforms > that can't handle time stamps past 2038. (It'd have trouble with > functions like 'stat', of course.) ... > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign Indeed, once glibc will have this support, it makes sense to have a gnulib that turns it on. => I agree, it should be named 'year2038'. Until that happens, however, i.e. while time() and stat() behave in unpredictable ways, it does not make sense IMO to put effort into making localtime() work right. > A similar point applies to some of the other modules you mentioned, > e.g., windows-uid. What do you mean? Is uid_t being replaced by a larger type on some platforms? Bruno
