Re: [TUHS] The 2038 bug...

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