Will there be that many 32 bit systems left by then? time_t these days tends to be 64 bits, and I think at least the Linux file systems store them that way. Microsoft counts time from January 1, 1980, so that buys them until 2048. :-) I'll be (G-d willing) 79 then; I hope around, but I also hope not overly involved with computers. :-) Arnold Niklas Karlsson <nikke.karlsson(a)gmail.com> wrote:

I’ll be 67 for the 2038 bug. Plenty of time to charge ridiculous hourly rates for being the old curmudgeon who still keeps a bunch of these systems running in his house for some combination of fun, nostalgia, and challenge. My gut tells me that this is going to be far less of a big deal than 2000. To (somewhat inaccurately) summarize: the problem with 2000 is that there was (and is, and will be in 2038) a whole bunch of COBOL doing the Really Important Stuff with two-digit year fields. Whereas, time_t is basically internal, right? Software is forever, but hardware, even with the best of intentions, after about 40 years or so, starts getting difficult to keep running (/pats Atari 2600 affectionately). So if you *can* rebuild the software for a newer architecture…then suddenly there’s a wider time_t and the 33d bit is suddenly 1 but nothing breaks. And if you can’t, you’re probably by that point running it in emulation anyway, at which point your emulation environment can know that 1/1/1970 is really whatever/2038, and your software is partying like it was just 1969. If you have need to maintain linearly incrementing time in your application, you do the sliding window thing that we did with COBOL and Y2K. Aside: the COBOL problem was made worse by IBM’s (IMHO very good) decision to provide problem-state instruction compatibility all the way from the (1964, IIRC) 360 to the present day, so for more than half a decade, you can just drop your Big Important COBOL onto the current incarnation of the 3x0/z and it’ll be perfectly happy. Adam

64-bit migration is the ideal solution. However there is a band-aid that can be applied to extend the life of 32-bit only systems. One could reclaim part of the previous epoch window going forward. That is, once 32-bit time_t rolls over, assume any value from -2 billion to some additional arbitrary positive time offset had indeed just rolled over. Add a whole 0x100000000 to it in a 64-bit context and evaluate (or evaluate against the old epoch ~+136 years). It means a 32-bit time_t in this context would instead mis-represent dates from 1902 forward to some arbitrary threshold as modern >2038 dates. But time_t was never meant to track dates outside of 'near term' relative to 'modern day' - eg +/- 68 years from 1970 when it was conceived. It's reasonable to assume as the use of such software has moved forward in time, its time reference should as well. -Alan H. On 2020-12-31 11:12, Larry McVoy wrote:

On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote: Emulation is the key problem. I still have a production server running on a Linode VM which was installed using Debian 6.0 using i386 binaries sometime in 2011. I kept it on 32-bits because it's more RAM efficient, and it would have been a pain to reconfigure all of its services if I were to reinstall it to use a 64-bit OS --- and Debian has had silky-smooth upgrades from Debian 6.0 all the way up to Debian 10.0 in 2019. There is some discussion of dropping i386 support in Debian, which may force the issue, but up until now, it's just been easier for me to do major updates every 2-3 years to the latest Debian stable, and rely on security updates in between major updates. Twenty years ago, one of larger customers for the company I was working for at the time (VA Linux Systems) was one of the new electronic stock exchanges, and they were using Linux boxes with PDP-11 emulators because their stock trading software was written in Macro-11 and running on RSTS/E. They had tried three times to rewrite it so it could run on something more modern, but each time, the rewrite had ended in failure. So they simply sharded the problem, so one x86 server running RSTS/E in emulation would service stocks symbols AAAA--ADZZ, and the next would service stocks AEAA--AFZZ, and so on. Given that this was back in 1999, I assume they had solved the Y2K problem one way or another, but even if they hadn't yet, I suspect it would have been easier for them to fix the problem by asking their dedicated Macro-11 Software Engineering team to fix it, than to ask that same team to help the other team put themselves out of a job (which for some reason, never seemed to happen successfully...) - Ted

Il 31/12/2020 alle 16:30, Warner Losh ha scritto: [...] On recent Linux/i386 kernels it's actually 64 bits. In practice, only users who are stuck with old i386 Linux versions will have a problem. -- Dario Niedermann -:- finger my email address for PGP key, etc. Also on the Internet at: <gopher://darioniedermann.it/> <https://www.darioniedermann.it/>

Il 06/01/2021 alle 18:08, Henry Bent ha scritto: 5.6 is the first 32-bit kernel with 64-bit time_t, according to: <https://lkml.org/lkml/2020/1/29/355?anz=web> -- Dario Niedermann -:- finger my email address for PGP key, etc. Also on the Internet at: <gopher://darioniedermann.it/> <https://www.darioniedermann.it/>

On Wed, 6 Jan 2021, Dario Niedermann wrote: 64 bits on my old-ish MacBook Pro and FreeBSD 10; don't know about Penguin/OS as one of them is dead forever and the other is still in mid-upgrade (Debian). I still reckon that 2038 will be "interesting", and who knows what epoch your smart kettle etc will be using (you know, the one that will switch itself on at your usual wake-up time, and make your coffee for you)? -- Dave

On Mon, 4 Jan 2021, Peter Jeremy wrote: My understanding is that it's been 1st Jan 1970 since at least Ed5, if not Ed6. The only systems I have that would care would be the various computers, and they are all NTP-synced (except the NBN modem/router takes its time from T$). Well, I don't care about the M$ epoch, and at 86 I might even get to see the world come to a grinding halt :-) Of course, I may be reliant upon M$ systems in hospitals etc... Interesting story about the S/360 though. As a side-issue I wonder how many COBOL programmers will still be around to maintain all that payroll software etc? -- Dave, who's kept his COBOL knowledge a secret in every job

On Mon, Jan 4, 2021 at 4:57 PM Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: Lots of older code also knew that pointers were 32 bits and could fit into an int, that the signal bitmask fit into 32 bits, etc. I feel like we have these crises every few years and we work around them. The issues here are perfectly familiar. A saving grace is that the timestamp fields in Unixy filesystems are almost invariably 64 bits and have been for a few decades now. Unlike y2k, the persistence issue is largely fixed except for ersatz binary formats, and most decently-maintained software hides the width of time behind a typedef. As for Ted's vignette about hand-coded systems in PDP-11 assembler running under emulation, I think the issue here is somewhat different: in this case, by and large, the software doesn't need rewriting, but rather recompilation on a new hardware and/or OS platform, possibly with some modifications to fix assumptions about type width. That's qualitatively different from rewriting from scratch in a different language on a radically different platform. Note I'm talking about Unix and Linux here, as opposed to other systems with similar epoch issues. Certainly there will be some breakage in 2038. But I suspect that we'll pull a y2k and the critical stuff will be mostly fixed by the time the epoch rolls over. The long tail will be annoying, as it was with y2k, but not necessarily critical. - Dan C.

Indeed! Also FORTRAN/RATFOR and BASIC, in my case; but especially COBOL: apart from everything else, too much like writing a novel to get anything done. On Tue, 5 Jan 2021, 05:50 Dave Horsfall, &lt;dave(a)horsfall.org&gt; wrote:

That's not too far wrong! (btw, Dave H., I seem to be trapped in your greylist) On Fri, 8 Jan 2021, 09:26 Nemo Nusquam, &lt;cym224(a)gmail.com&gt; wrote:

I'll be 41 next month. Den sön 10 jan. 2021 kl 08:23 skrev Valdimar Sigurdsson &lt;ricercar(a)lycos.com