Re: [TUHS] The 2038 bug...

[Peter Jeremy via TUHS <tuhs@minnie.tuhs.org>]

[-- 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 --]