5 Jan
2021
5 Jan
'21
3:49 a.m.
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