The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [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: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  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 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  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...
  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...
  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...
  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  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...
  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
                   ` (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 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...
@ 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

* 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...
  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 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

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

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git