* [TUHS] The 2038 bug... @ 2020-12-31 7:19 Dave Horsfall 2020-12-31 7:24 ` Niklas Karlsson ` (4 more replies) 0 siblings, 5 replies; 34+ messages in thread From: Dave Horsfall @ 2020-12-31 7:19 UTC (permalink / raw) To: The Eunuchs Hysterical Society As the new year is about to kick in (down-under anyway), it got me to thinking (always dangerous): how many here will be around for it to pick up the pieces that are no doubt still lying around? I'll be about the ripe old age of 85, so I may be around to see the Imminent Death of the Internet (Film at 11). 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my favourite Heinlein books. Others? -- Dave ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 7:19 [TUHS] The 2038 bug Dave Horsfall @ 2020-12-31 7:24 ` Niklas Karlsson 2020-12-31 8:10 ` arnold 2021-01-04 8:22 ` Peter Jeremy via TUHS ` (3 subsequent siblings) 4 siblings, 1 reply; 34+ messages in thread From: Niklas Karlsson @ 2020-12-31 7:24 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 664 bytes --] I'll be a mere 58, so not even retired yet. I fear it will be a very interesting time, in the "May you live in interesting times" sense. Niklas Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall <dave@horsfall.org>: > As the new year is about to kick in (down-under anyway), it got me to > thinking (always dangerous): how many here will be around for it to pick > up the pieces that are no doubt still lying around? > > I'll be about the ripe old age of 85, so I may be around to see the > Imminent Death of the Internet (Film at 11). > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > favourite Heinlein books. > > Others? > > -- Dave > [-- Attachment #2: Type: text/html, Size: 1055 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 7:24 ` Niklas Karlsson @ 2020-12-31 8:10 ` arnold 2020-12-31 15:30 ` Warner Losh 2020-12-31 19:18 ` Bakul Shah 0 siblings, 2 replies; 34+ messages in thread From: arnold @ 2020-12-31 8:10 UTC (permalink / raw) To: tuhs, nikke.karlsson 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@gmail.com> wrote: > I'll be a mere 58, so not even retired yet. I fear it will be a very > interesting time, in the "May you live in interesting times" sense. > > Niklas > > Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall <dave@horsfall.org>: > > > As the new year is about to kick in (down-under anyway), it got me to > > thinking (always dangerous): how many here will be around for it to pick > > up the pieces that are no doubt still lying around? > > > > I'll be about the ripe old age of 85, so I may be around to see the > > Imminent Death of the Internet (Film at 11). > > > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > > favourite Heinlein books. > > > > Others? > > > > -- Dave > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 8:10 ` arnold @ 2020-12-31 15:30 ` Warner Losh 2020-12-31 16:09 ` Adam Thornton 2021-01-06 16:32 ` Dario Niedermann 2020-12-31 19:18 ` Bakul Shah 1 sibling, 2 replies; 34+ messages in thread From: Warner Losh @ 2020-12-31 15:30 UTC (permalink / raw) To: Arnold Robbins; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1805 bytes --] On Thu, Dec 31, 2020, 1:10 AM <arnold@skeeve.com> wrote: > Will there be that many 32 bit systems left by then? FreeBSD has 64bit time_t everywhere except i386. We looked at compat shims and found like 200 system calls would need compat shims to keep a stable ABI. Creating a new ABI is mostly a matter of fixing the places that know time_t is 32 bit on i386. Most likely, though, it will just be retired 15 years or so before the deadline. time_t these > days tends to be 64 bits, and I think at least the Linux file systems > store them that way. Time_t was still 32 bits last I checked on i386 and a few others... 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. :-) > I'll only be 72... with LORAN-C retired in the US the last of the potentially problematic[*] code I've deployed is gone. Warner [*] Purely from a 32 bit time_t perspective. Arnold > > Niklas Karlsson <nikke.karlsson@gmail.com> wrote: > > > I'll be a mere 58, so not even retired yet. I fear it will be a very > > interesting time, in the "May you live in interesting times" sense. > > > > Niklas > > > > Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall <dave@horsfall.org>: > > > > > As the new year is about to kick in (down-under anyway), it got me to > > > thinking (always dangerous): how many here will be around for it to > pick > > > up the pieces that are no doubt still lying around? > > > > > > I'll be about the ripe old age of 85, so I may be around to see the > > > Imminent Death of the Internet (Film at 11). > > > > > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > > > favourite Heinlein books. > > > > > > Others? > > > > > > -- Dave > > > > [-- Attachment #2: Type: text/html, Size: 3366 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 15:30 ` Warner Losh @ 2020-12-31 16:09 ` Adam Thornton 2020-12-31 16:12 ` Larry McVoy 2020-12-31 18:36 ` Theodore Ts'o 2021-01-06 16:32 ` Dario Niedermann 1 sibling, 2 replies; 34+ messages in thread From: Adam Thornton @ 2020-12-31 16:09 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 16:09 ` Adam Thornton @ 2020-12-31 16:12 ` Larry McVoy 2021-01-11 7:18 ` alan 2020-12-31 18:36 ` Theodore Ts'o 1 sibling, 1 reply; 34+ messages in thread From: Larry McVoy @ 2020-12-31 16:12 UTC (permalink / raw) To: Adam Thornton; +Cc: The Eunuchs Hysterical Society On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote: > Whereas, time_t is basically internal, right? time_t is used in syscalls, see Warner's email about i386. It's a mess for 32 bit kernels. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 16:12 ` Larry McVoy @ 2021-01-11 7:18 ` alan 2021-01-11 14:01 ` Stuart Remphrey 0 siblings, 1 reply; 34+ messages in thread From: alan @ 2021-01-11 7:18 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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: >> Whereas, time_t is basically internal, right? > > time_t is used in syscalls, see Warner's email about i386. It's a > mess for 32 bit kernels. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-11 7:18 ` alan @ 2021-01-11 14:01 ` Stuart Remphrey 0 siblings, 0 replies; 34+ messages in thread From: Stuart Remphrey @ 2021-01-11 14:01 UTC (permalink / raw) To: alan; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1581 bytes --] > 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. That seems a reasonable 2038 bandaid: analogous to Y2K reinterpreting 2-digit decimal dates as a different/higher year range than 1900-1990; similar in effect to making 32-bit time_t unsigned. On Mon, 11 Jan 2021, 15:28 , <alan@alanlee.org> wrote: > > 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: > >> Whereas, time_t is basically internal, right? > > > > time_t is used in syscalls, see Warner's email about i386. It's a > > mess for 32 bit kernels. > [-- Attachment #2: Type: text/html, Size: 2194 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 16:09 ` Adam Thornton 2020-12-31 16:12 ` Larry McVoy @ 2020-12-31 18:36 ` Theodore Ts'o 2020-12-31 21:34 ` Warner Losh 1 sibling, 1 reply; 34+ messages in thread From: Theodore Ts'o @ 2020-12-31 18:36 UTC (permalink / raw) To: Adam Thornton; +Cc: The Eunuchs Hysterical Society On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote: > > 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. 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 18:36 ` Theodore Ts'o @ 2020-12-31 21:34 ` Warner Losh 0 siblings, 0 replies; 34+ messages in thread From: Warner Losh @ 2020-12-31 21:34 UTC (permalink / raw) To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1621 bytes --] On Thu, Dec 31, 2020 at 11:37 AM Theodore Ts'o <tytso@mit.edu> wrote: > 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...) > This is the sort of reason why QBUS x86 machines exist... Not cheap, or easy to come by these days, but they filled a niche of emulation but with access to real hardware... Nor easy to find with a web search, it seems :(. There's a number of nuclear power plants that employ MACRO-11 programmers because they can't swap out the old gear w/o going through a prohibitively expensive recertification process... It's cheaper to hire and train good programmers than it is to go through that process :(. Warner [-- Attachment #2: Type: text/html, Size: 2064 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 15:30 ` Warner Losh 2020-12-31 16:09 ` Adam Thornton @ 2021-01-06 16:32 ` Dario Niedermann 2021-01-06 17:08 ` Henry Bent 2021-01-06 21:09 ` Dave Horsfall 1 sibling, 2 replies; 34+ messages in thread From: Dario Niedermann @ 2021-01-06 16:32 UTC (permalink / raw) To: tuhs Il 31/12/2020 alle 16:30, Warner Losh ha scritto: >On Thu, Dec 31, 2020, 1:10 AM <arnold@skeeve.com> wrote: [...] >>time_t these days tends to be 64 bits, and I think at least the Linux >>file systems store them that way. > >Time_t was still 32 bits last I checked on i386 and a few others... 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/> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-06 16:32 ` Dario Niedermann @ 2021-01-06 17:08 ` Henry Bent 2021-01-06 18:05 ` Dario Niedermann 2021-01-06 18:20 ` Michael Kjörling 2021-01-06 21:09 ` Dave Horsfall 1 sibling, 2 replies; 34+ messages in thread From: Henry Bent @ 2021-01-06 17:08 UTC (permalink / raw) To: TUHS main list [-- Attachment #1: Type: text/plain, Size: 644 bytes --] On Wed, 6 Jan 2021 at 11:40, Dario Niedermann <dario@darioniedermann.it> wrote: > Il 31/12/2020 alle 16:30, Warner Losh ha scritto: > > >On Thu, Dec 31, 2020, 1:10 AM <arnold@skeeve.com> wrote: > [...] > >>time_t these days tends to be 64 bits, and I think at least the Linux > >>file systems store them that way. > > > >Time_t was still 32 bits last I checked on i386 and a few others... > > 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. > Do you happen to know what the cutoff is? Are 2.6 kernels (still very common) safe? 3.x? 4.x? -Henry [-- Attachment #2: Type: text/html, Size: 1081 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-06 17:08 ` Henry Bent @ 2021-01-06 18:05 ` Dario Niedermann 2021-01-06 18:20 ` Michael Kjörling 1 sibling, 0 replies; 34+ messages in thread From: Dario Niedermann @ 2021-01-06 18:05 UTC (permalink / raw) To: tuhs Il 06/01/2021 alle 18:08, Henry Bent ha scritto: >On Wed, 6 Jan 2021 at 11:40, Dario Niedermann <dario@darioniedermann.it> >wrote: > >>Il 31/12/2020 alle 16:30, Warner Losh ha scritto: >>[...] >>>Time_t was still 32 bits last I checked on i386 and a few others... >> >> 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. > >Do you happen to know what the cutoff is? Are 2.6 kernels (still very >common) safe? 3.x? 4.x? 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/> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-06 17:08 ` Henry Bent 2021-01-06 18:05 ` Dario Niedermann @ 2021-01-06 18:20 ` Michael Kjörling 1 sibling, 0 replies; 34+ messages in thread From: Michael Kjörling @ 2021-01-06 18:20 UTC (permalink / raw) To: tuhs On 6 Jan 2021 12:08 -0500, from henry.r.bent@gmail.com (Henry Bent): >> 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. > > Do you happen to know what the cutoff is? Are 2.6 kernels (still very > common) safe? 3.x? 4.x? I haven't dug particularly deeply, but unless I am missing something, Debian Buster's 4.19 kernel seems to map `time_t` to plain `long` regardless of architecture. I don't have an i386 architecture system handy, but wouldn't that make it 32 bits wide on i386 & Co? linux/time.h: struct timespec { __kernel_time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ }; asm-generic/posix_types.h: #ifndef __kernel_long_t typedef long __kernel_long_t; typedef unsigned long __kernel_ulong_t; #endif /* ... */ typedef __kernel_long_t __kernel_time_t; Both from Debian's linux-libc-dev package, version 4.19.160-2, amd64 architecture. If that's right, then I'd definitely expect anything 2.x and 3.x to be unsafe, and 4.x to at best be suspect; so Dario's mention of 5.6 doesn't sound unreasonable as a first guess. We've got maybe fifteen years before this starts to become a real issue. Time to start working on those upgrade plans... -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-06 16:32 ` Dario Niedermann 2021-01-06 17:08 ` Henry Bent @ 2021-01-06 21:09 ` Dave Horsfall 1 sibling, 0 replies; 34+ messages in thread From: Dave Horsfall @ 2021-01-06 21:09 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 6 Jan 2021, Dario Niedermann wrote: > 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. 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 8:10 ` arnold 2020-12-31 15:30 ` Warner Losh @ 2020-12-31 19:18 ` Bakul Shah 1 sibling, 0 replies; 34+ messages in thread From: Bakul Shah @ 2020-12-31 19:18 UTC (permalink / raw) To: TUHS 2038 is closer than 2000 was to the present time and will be upon us before we are ready for it! I suspect people will still be running 32 bit systems in all sorts of places and running the Unix equivalent of “dusty decks” for critical systems. May be even in emulation mode! Who’d want to fund rewrites of large software monoliths? I imagine I will still be playing with this ultimate toy of computing in 2038, if I am able! Still writing new programs for fun along with everything else! People will still be writing “make” replacements, inventing new programming languages that won’t be much of an improvement over the present lot, and arguing over the same old things. Assuming we haven’t crossed the AI singularity. Which I doubt. > On Dec 31, 2020, at 12:10 AM, arnold@skeeve.com wrote: > > 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@gmail.com> wrote: > >> I'll be a mere 58, so not even retired yet. I fear it will be a very >> interesting time, in the "May you live in interesting times" sense. >> Niklas >> Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall <dave@horsfall.org>: >>> As the new year is about to kick in (down-under anyway), it got me to >>> thinking (always dangerous): how many here will be around for it to pick >>> up the pieces that are no doubt still lying around? >>> I'll be about the ripe old age of 85, so I may be around to see the >>> Imminent Death of the Internet (Film at 11). >>> 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my >>> favourite Heinlein books. >>> Others? >>> -- Dave ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 7:19 [TUHS] The 2038 bug Dave Horsfall 2020-12-31 7:24 ` Niklas Karlsson @ 2021-01-04 8:22 ` Peter Jeremy via TUHS 2021-01-04 9:13 ` Angus Robinson 2021-01-04 21:49 ` Dave Horsfall 2021-01-04 8:59 ` Sergio Pedraja ` (2 subsequent siblings) 4 siblings, 2 replies; 34+ messages in thread From: Peter Jeremy via TUHS @ 2021-01-04 8:22 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1455 bytes --] On 2020-Dec-31 18:19:39 +1100, Dave Horsfall <dave@horsfall.org> wrote: >As the new year is about to kick in (down-under anyway), it got me to >thinking (always dangerous): how many here will be around for it to pick >up the pieces that are no doubt still lying around? Alternatively, my understanding is that the Unix epoch changed on several occasions in the early days. Presumably the knowledge of how to achieve this hasn't been lost. (Though actually performing an epoch rollover may be more difficult today). I suspect that 2038 may actually wind up being more serious than Y2K because there are now far more embedded systems than there were then but it's not clear that the designers of those systems learnt the lesson from Y2K. A few weeks ago I tried to count the number of CPUs in my bedroom, bathroom and study - my best guess is around 2 dozen. Admittedly, I think relatively few of those will be concerned about epoch rollover. Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch rolling over in 2048. Between those two, the IBM S/360 epoch rolls over in 2042 - the Z-series appears to have glued another 8 bits onto the MSB end of the TOD clock but that won't help all those S/360 and S/370 binaries that are still being run. And they are just the well- known ones. I expect that there are lots of embedded systems running custom epochs with weird rollover dates. -- Peter Jeremy [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 963 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-04 8:22 ` Peter Jeremy via TUHS @ 2021-01-04 9:13 ` Angus Robinson 2021-01-04 21:49 ` Dave Horsfall 1 sibling, 0 replies; 34+ messages in thread From: Angus Robinson @ 2021-01-04 9:13 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1733 bytes --] One wonders if pacemakers or any other devices that are inserted into the human body by then would be susceptible to the 2038 bug as well. Kind Regards, Angus Robinson On Mon, Jan 4, 2021 at 10:46 AM Peter Jeremy via TUHS <tuhs@minnie.tuhs.org> wrote: > On 2020-Dec-31 18:19:39 +1100, Dave Horsfall <dave@horsfall.org> wrote: > >As the new year is about to kick in (down-under anyway), it got me to > >thinking (always dangerous): how many here will be around for it to pick > >up the pieces that are no doubt still lying around? > > Alternatively, my understanding is that the Unix epoch changed on > several occasions in the early days. Presumably the knowledge of > how to achieve this hasn't been lost. (Though actually performing > an epoch rollover may be more difficult today). > > I suspect that 2038 may actually wind up being more serious than Y2K > because there are now far more embedded systems than there were then > but it's not clear that the designers of those systems learnt the > lesson from Y2K. A few weeks ago I tried to count the number of > CPUs in my bedroom, bathroom and study - my best guess is around 2 > dozen. Admittedly, I think relatively few of those will be concerned > about epoch rollover. > > Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch > rolling over in 2048. Between those two, the IBM S/360 epoch rolls > over in 2042 - the Z-series appears to have glued another 8 bits onto > the MSB end of the TOD clock but that won't help all those S/360 and > S/370 binaries that are still being run. And they are just the well- > known ones. I expect that there are lots of embedded systems running > custom epochs with weird rollover dates. > > -- > Peter Jeremy > [-- Attachment #2: Type: text/html, Size: 2333 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-04 8:22 ` Peter Jeremy via TUHS 2021-01-04 9:13 ` Angus Robinson @ 2021-01-04 21:49 ` Dave Horsfall 2021-01-04 21:56 ` Warner Losh 2021-01-07 22:56 ` Stuart Remphrey 1 sibling, 2 replies; 34+ messages in thread From: Dave Horsfall @ 2021-01-04 21:49 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Mon, 4 Jan 2021, Peter Jeremy wrote: > Alternatively, my understanding is that the Unix epoch changed on > several occasions in the early days. Presumably the knowledge of how to > achieve this hasn't been lost. (Though actually performing an epoch > rollover may be more difficult today). My understanding is that it's been 1st Jan 1970 since at least Ed5, if not Ed6. > I suspect that 2038 may actually wind up being more serious than Y2K > because there are now far more embedded systems than there were then but > it's not clear that the designers of those systems learnt the lesson > from Y2K. A few weeks ago I tried to count the number of CPUs in my > bedroom, bathroom and study - my best guess is around 2 dozen. > Admittedly, I think relatively few of those will be concerned about > epoch rollover. 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$). > Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch > rolling over in 2048. Between those two, the IBM S/360 epoch rolls over > in 2042 - the Z-series appears to have glued another 8 bits onto the MSB > end of the TOD clock but that won't help all those S/360 and S/370 > binaries that are still being run. And they are just the well- known > ones. I expect that there are lots of embedded systems running custom > epochs with weird rollover dates. 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-04 21:49 ` Dave Horsfall @ 2021-01-04 21:56 ` Warner Losh 2021-01-05 18:05 ` Dan Cross 2021-01-07 22:56 ` Stuart Remphrey 1 sibling, 1 reply; 34+ messages in thread From: Warner Losh @ 2021-01-04 21:56 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1042 bytes --] On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall <dave@horsfall.org> wrote: > On Mon, 4 Jan 2021, Peter Jeremy wrote: > > > Alternatively, my understanding is that the Unix epoch changed on > > several occasions in the early days. Presumably the knowledge of how to > > achieve this hasn't been lost. (Though actually performing an epoch > > rollover may be more difficult today). > > My understanding is that it's been 1st Jan 1970 since at least Ed5, if not > Ed6. > It's been that way since the 4th edition. In the 3rd edition it was the number of 60Hz ticks since 1972, along with this note: "This guarantees a crisis every 2.26 years." Rebasing the epoch would be... tricky... lots of math is done assuming an origin of 1970, and not all of it is obvious to even concerted analysis. Less ugly would be to declare time_t to be unsigned instead of signed... It would break less code... Making time_t 64 bits also breaks code, even if you declare you don't care about binary compat since many older apps know time_t is 32-bits. Warner [-- Attachment #2: Type: text/html, Size: 1538 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-04 21:56 ` Warner Losh @ 2021-01-05 18:05 ` Dan Cross 2021-01-06 7:21 ` Warner Losh 0 siblings, 1 reply; 34+ messages in thread From: Dan Cross @ 2021-01-05 18:05 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2503 bytes --] On Mon, Jan 4, 2021 at 4:57 PM Warner Losh <imp@bsdimp.com> wrote: > On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall <dave@horsfall.org> wrote: > >> On Mon, 4 Jan 2021, Peter Jeremy wrote: >> >> > Alternatively, my understanding is that the Unix epoch changed on >> > several occasions in the early days. Presumably the knowledge of how >> to >> > achieve this hasn't been lost. (Though actually performing an epoch >> > rollover may be more difficult today). >> >> My understanding is that it's been 1st Jan 1970 since at least Ed5, if >> not >> Ed6. >> > > It's been that way since the 4th edition. > > In the 3rd edition it was the number of 60Hz ticks since 1972, along with > this note: "This guarantees a crisis every 2.26 years." > > Rebasing the epoch would be... tricky... lots of math is done assuming an > origin of 1970, and not all of it is obvious to even concerted analysis. > > Less ugly would be to declare time_t to be unsigned instead of signed... > It would break less code... Making time_t 64 bits also breaks code, even if > you declare you don't care about binary compat since many older apps know > time_t is 32-bits. > 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. [-- Attachment #2: Type: text/html, Size: 3302 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-05 18:05 ` Dan Cross @ 2021-01-06 7:21 ` Warner Losh 0 siblings, 0 replies; 34+ messages in thread From: Warner Losh @ 2021-01-06 7:21 UTC (permalink / raw) To: Dan Cross; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3913 bytes --] On Tue, Jan 5, 2021 at 11:06 AM Dan Cross <crossd@gmail.com> wrote: > On Mon, Jan 4, 2021 at 4:57 PM Warner Losh <imp@bsdimp.com> wrote: > >> On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall <dave@horsfall.org> wrote: >> >>> On Mon, 4 Jan 2021, Peter Jeremy wrote: >>> >>> > Alternatively, my understanding is that the Unix epoch changed on >>> > several occasions in the early days. Presumably the knowledge of how >>> to >>> > achieve this hasn't been lost. (Though actually performing an epoch >>> > rollover may be more difficult today). >>> >>> My understanding is that it's been 1st Jan 1970 since at least Ed5, if >>> not >>> Ed6. >>> >> >> It's been that way since the 4th edition. >> >> In the 3rd edition it was the number of 60Hz ticks since 1972, along with >> this note: "This guarantees a crisis every 2.26 years." >> >> Rebasing the epoch would be... tricky... lots of math is done assuming >> an origin of 1970, and not all of it is obvious to even concerted analysis. >> >> Less ugly would be to declare time_t to be unsigned instead of signed... >> It would break less code... Making time_t 64 bits also breaks code, even if >> you declare you don't care about binary compat since many older apps know >> time_t is 32-bits. >> > > 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. > True. The issues were understood for years before compilers started warning about the issue on a wide-scale basis. There's currently no warnings for many of the common time_t type handling mistakes since they aren't considered errors in other contexts. So it makes the problem less visible. > 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. > A larger problem, though, is where time_t is 64 bits, but on-disk format is 32-bits... And often times recompiling old software on new systems with different sized types can be a crap shoot. For software that's well understood, sure, an analysis can be undertaken, and it will likely work. For older code, that uses tricks to compute different types of dates, it's also likely more prone to overflow even with the recompile... > 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. > I suspect that many of the issues can be fixed between now and then, but w/o some effort, they will persist... Though it doesn't take too many errors in a critical system for there to be a catastrophic failure. Without publicity like y2k got, it's unclear the outcome. I'll note with pride that my state replaced its unemployment system today with a new one. The old one was only 44 years old and not even the oldest in the nation... The long hand of the past appears in unexpected locations that are resource constrained. Warner > - Dan C. > > [-- Attachment #2: Type: text/html, Size: 5651 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-04 21:49 ` Dave Horsfall 2021-01-04 21:56 ` Warner Losh @ 2021-01-07 22:56 ` Stuart Remphrey 2021-01-08 1:25 ` Nemo Nusquam 1 sibling, 1 reply; 34+ messages in thread From: Stuart Remphrey @ 2021-01-07 22:56 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2205 bytes --] > Dave, who's kept his COBOL knowledge a secret in every job 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, <dave@horsfall.org> wrote: > On Mon, 4 Jan 2021, Peter Jeremy wrote: > > > Alternatively, my understanding is that the Unix epoch changed on > > several occasions in the early days. Presumably the knowledge of how to > > achieve this hasn't been lost. (Though actually performing an epoch > > rollover may be more difficult today). > > My understanding is that it's been 1st Jan 1970 since at least Ed5, if not > Ed6. > > > I suspect that 2038 may actually wind up being more serious than Y2K > > because there are now far more embedded systems than there were then but > > it's not clear that the designers of those systems learnt the lesson > > from Y2K. A few weeks ago I tried to count the number of CPUs in my > > bedroom, bathroom and study - my best guess is around 2 dozen. > > Admittedly, I think relatively few of those will be concerned about > > epoch rollover. > > 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$). > > > Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch > > rolling over in 2048. Between those two, the IBM S/360 epoch rolls over > > in 2042 - the Z-series appears to have glued another 8 bits onto the MSB > > end of the TOD clock but that won't help all those S/360 and S/370 > > binaries that are still being run. And they are just the well- known > > ones. I expect that there are lots of embedded systems running custom > > epochs with weird rollover dates. > > 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 > [-- Attachment #2: Type: text/html, Size: 2800 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-07 22:56 ` Stuart Remphrey @ 2021-01-08 1:25 ` Nemo Nusquam 2021-01-10 6:56 ` Stuart Remphrey 0 siblings, 1 reply; 34+ messages in thread From: Nemo Nusquam @ 2021-01-08 1:25 UTC (permalink / raw) To: tuhs On 01/07/21 17:56, Stuart Remphrey wrote (in part): > > Dave, who's kept his COBOL knowledge a secret in every job > > Indeed! [...]; but especially COBOL: apart from everything else, too > much like writing a novel to get anything done. As long as we are bashing COBOL, I recall that someone -- name forgotten -- wrote a parody that contained statements such as "Verily, let the noble variable N be assigned the value known as one". N. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-08 1:25 ` Nemo Nusquam @ 2021-01-10 6:56 ` Stuart Remphrey 0 siblings, 0 replies; 34+ messages in thread From: Stuart Remphrey @ 2021-01-10 6:56 UTC (permalink / raw) To: Nemo Nusquam; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 612 bytes --] 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, <cym224@gmail.com> wrote: > On 01/07/21 17:56, Stuart Remphrey wrote (in part): > > > Dave, who's kept his COBOL knowledge a secret in every job > > > > Indeed! [...]; but especially COBOL: apart from everything else, too > > much like writing a novel to get anything done. > As long as we are bashing COBOL, I recall that someone -- name forgotten > -- wrote a parody that contained statements such as "Verily, let the > noble variable N be assigned the value known as one". > > N. > [-- Attachment #2: Type: text/html, Size: 1081 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 7:19 [TUHS] The 2038 bug Dave Horsfall 2020-12-31 7:24 ` Niklas Karlsson 2021-01-04 8:22 ` Peter Jeremy via TUHS @ 2021-01-04 8:59 ` Sergio Pedraja 2021-01-07 22:50 ` Stuart Remphrey 2021-01-10 7:16 ` Valdimar Sigurdsson 4 siblings, 0 replies; 34+ messages in thread From: Sergio Pedraja @ 2021-01-04 8:59 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 290 bytes --] Great choice, talking as Sci-fi fan (from my childhood). It was published in Spain (my country) by 1968. El jue., 31 dic. 2020 8:21, Dave Horsfall <dave@horsfall.org> escribió: > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > favourite Heinlein books. > [-- Attachment #2: Type: text/html, Size: 799 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 7:19 [TUHS] The 2038 bug Dave Horsfall ` (2 preceding siblings ...) 2021-01-04 8:59 ` Sergio Pedraja @ 2021-01-07 22:50 ` Stuart Remphrey 2021-01-10 7:16 ` Valdimar Sigurdsson 4 siblings, 0 replies; 34+ messages in thread From: Stuart Remphrey @ 2021-01-07 22:50 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 924 bytes --] Hmm, 76 (hopefully), retired (hopefully), so won't care (hopefully). Unless retired & broke & can still concentrate (*somewhat doubtful, even now?!*) -- in which case a good opportunity for truly excessive overcharging to find & fix all those 32-bit time_t syscalls & re-retire rich, happy, and braindead... (*Hi Dave, from PTA/PTC days, btw; reminds me of SFA forms, ptcburp at Bond Uni Research Park*) On Thu, 31 Dec 2020, 15:20 Dave Horsfall, <dave@horsfall.org> wrote: > As the new year is about to kick in (down-under anyway), it got me to > thinking (always dangerous): how many here will be around for it to pick > up the pieces that are no doubt still lying around? > > I'll be about the ripe old age of 85, so I may be around to see the > Imminent Death of the Internet (Film at 11). > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > favourite Heinlein books. > > Others? > > -- Dave > [-- Attachment #2: Type: text/html, Size: 1394 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 7:19 [TUHS] The 2038 bug Dave Horsfall ` (3 preceding siblings ...) 2021-01-07 22:50 ` Stuart Remphrey @ 2021-01-10 7:16 ` Valdimar Sigurdsson 2021-01-10 7:24 ` Niklas Karlsson 2021-01-10 10:15 ` Stuart Remphrey 4 siblings, 2 replies; 34+ messages in thread From: Valdimar Sigurdsson @ 2021-01-10 7:16 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 505 bytes --] I for one will be 42. On 12/31/20 1:19 AM, Dave Horsfall wrote: > As the new year is about to kick in (down-under anyway), it got me to > thinking (always dangerous): how many here will be around for it to pick > up the pieces that are no doubt still lying around? > I'll be about the ripe old age of 85, so I may be around to see the > Imminent Death of the Internet (Film at 11). > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > favourite Heinlein books. > Others? > -- Dave > [-- Attachment #2: Type: text/html, Size: 1003 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-10 7:16 ` Valdimar Sigurdsson @ 2021-01-10 7:24 ` Niklas Karlsson 2021-01-10 10:15 ` Stuart Remphrey 1 sibling, 0 replies; 34+ messages in thread From: Niklas Karlsson @ 2021-01-10 7:24 UTC (permalink / raw) To: Valdimar Sigurdsson; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 651 bytes --] I'll be 41 next month. Den sön 10 jan. 2021 kl 08:23 skrev Valdimar Sigurdsson <ricercar@lycos.com >: > I for one will be 42. > > > On 12/31/20 1:19 AM, Dave Horsfall wrote: > > As the new year is about to kick in (down-under anyway), it got me to > thinking (always dangerous): how many here will be around for it to pick > up the pieces that are no doubt still lying around? > > I'll be about the ripe old age of 85, so I may be around to see the > Imminent Death of the Internet (Film at 11). > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > favourite Heinlein books. > > Others? > > -- Dave > > [-- Attachment #2: Type: text/html, Size: 1237 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2021-01-10 7:16 ` Valdimar Sigurdsson 2021-01-10 7:24 ` Niklas Karlsson @ 2021-01-10 10:15 ` Stuart Remphrey 1 sibling, 0 replies; 34+ messages in thread From: Stuart Remphrey @ 2021-01-10 10:15 UTC (permalink / raw) To: Valdimar Sigurdsson; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 847 bytes --] By which time you may well find yourself managing a system through 2038 transition -- whilst your own age is the ultimate answer, but to what question? (getting a little off-topic, unless Sirius Cybernetics Corp developed their systems on Unix?) On Sun, 10 Jan 2021, 15:23 Valdimar Sigurdsson, <ricercar@lycos.com> wrote: > I for one will be 42. > > > On 12/31/20 1:19 AM, Dave Horsfall wrote: > > As the new year is about to kick in (down-under anyway), it got me to > thinking (always dangerous): how many here will be around for it to pick > up the pieces that are no doubt still lying around? > > I'll be about the ripe old age of 85, so I may be around to see the > Imminent Death of the Internet (Film at 11). > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > favourite Heinlein books. > > Others? > > -- Dave > > [-- Attachment #2: Type: text/html, Size: 1548 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug...
@ 2020-12-31 15:05 M Douglas McIlroy
2020-12-31 16:51 ` arnold
0 siblings, 1 reply; 34+ messages in thread
From: M Douglas McIlroy @ 2020-12-31 15:05 UTC (permalink / raw)
To: tuhs
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
> I'll be (G-d willing) 79 then; I hope around, but I also hope not
> overly involved with computers.
From the vantage point of 88, I can attest to the permanence of
computing's grip. I guess the key word is "overly". The only code
I've written in the last couple of weeks is a few lines of PostScript
to touch up my seasonal map/greeting card, the creative part of
which is at www.cs.dartmouth.edu/~doug/2020map.pdf.
Doug
[-- Attachment #2: Type: text/html, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 15:05 M Douglas McIlroy @ 2020-12-31 16:51 ` arnold 2020-12-31 23:31 ` Steffen Nurpmeso 0 siblings, 1 reply; 34+ messages in thread From: arnold @ 2020-12-31 16:51 UTC (permalink / raw) To: tuhs, m.douglas.mcilroy I wrote: > > I'll be (G-d willing) 79 then; I hope around, but I also hope not > > overly involved with computers. M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> wrote: > From the vantage point of 88, I can attest to the permanence of > computing's grip. I admire and am continually amazed at how acive you are; I hope I will still have all my faculties at 88 as you do. Best wishes to you and all the list for a Happy New Year! Arnold ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... 2020-12-31 16:51 ` arnold @ 2020-12-31 23:31 ` Steffen Nurpmeso 0 siblings, 0 replies; 34+ messages in thread From: Steffen Nurpmeso @ 2020-12-31 23:31 UTC (permalink / raw) To: tuhs arnold@skeeve.com wrote in <202012311651.0BVGpY4Y016626@freefriends.org>: |>> I'll be (G-d willing) 79 then; I hope around, but I also hope not |>> overly involved with computers. | |M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> wrote: | |> From the vantage point of 88, I can attest to the permanence of |> computing's grip. | |I admire and am continually amazed at how acive you are; I hope |I will still have all my faculties at 88 as you do. I became a bit frightened by the sheer size of the icy ground. |Best wishes to you and all the list for a Happy New Year! A happy and healthy 2021 everybody! Greetings and Ciao from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [TUHS] The 2038 bug... @ 2021-01-09 8:44 Norman Wilson 0 siblings, 0 replies; 34+ messages in thread From: Norman Wilson @ 2021-01-09 8:44 UTC (permalink / raw) To: tuhs Warner Losh: Less ugly would be to declare time_t to be unsigned instead of signed... It would break less code... Making time_t 64 bits also breaks code, even if you declare you don't care about binary compat since many older apps know time_t is 32-bits. === I remember chatting in 1998 with a consultant who worked with clients in the financial industry. They still used 32-bit systems at the time, and had already converted critical programs (I don't know whether that included parts of libc or they had their own conversion routines) to make time_t unsigned. It mattered early to those folks because of 40-year bonds. That suggests to me that the financial-services world may have a head start on the 2038 problem, but I fear many others are still lagging behind. 64 bits will help but not as much for embedded systems and legacy stuff. Us hobbyists will doubtless have fun too, as we already do (ask Warren) when running the earliest existing UNIX images, in which times are stored in sixtieths of a second. Norman Wilson Toronto ON ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2021-01-11 14:02 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-31 7:19 [TUHS] The 2038 bug Dave Horsfall 2020-12-31 7:24 ` Niklas Karlsson 2020-12-31 8:10 ` arnold 2020-12-31 15:30 ` Warner Losh 2020-12-31 16:09 ` Adam Thornton 2020-12-31 16:12 ` Larry McVoy 2021-01-11 7:18 ` alan 2021-01-11 14:01 ` Stuart Remphrey 2020-12-31 18:36 ` Theodore Ts'o 2020-12-31 21:34 ` Warner Losh 2021-01-06 16:32 ` Dario Niedermann 2021-01-06 17:08 ` Henry Bent 2021-01-06 18:05 ` Dario Niedermann 2021-01-06 18:20 ` Michael Kjörling 2021-01-06 21:09 ` Dave Horsfall 2020-12-31 19:18 ` Bakul Shah 2021-01-04 8:22 ` Peter Jeremy via TUHS 2021-01-04 9:13 ` Angus Robinson 2021-01-04 21:49 ` Dave Horsfall 2021-01-04 21:56 ` Warner Losh 2021-01-05 18:05 ` Dan Cross 2021-01-06 7:21 ` Warner Losh 2021-01-07 22:56 ` Stuart Remphrey 2021-01-08 1:25 ` Nemo Nusquam 2021-01-10 6:56 ` Stuart Remphrey 2021-01-04 8:59 ` Sergio Pedraja 2021-01-07 22:50 ` Stuart Remphrey 2021-01-10 7:16 ` Valdimar Sigurdsson 2021-01-10 7:24 ` Niklas Karlsson 2021-01-10 10:15 ` Stuart Remphrey 2020-12-31 15:05 M Douglas McIlroy 2020-12-31 16:51 ` arnold 2020-12-31 23:31 ` Steffen Nurpmeso 2021-01-09 8:44 Norman Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).