[TUHS] The 2038 bug...

Angus Robinson angus at fairhaven.za.net
Mon Jan 4 19:13:40 AEST 2021

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 at minnie.tuhs.org>

> On 2020-Dec-31 18:19:39 +1100, Dave Horsfall <dave at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/1807316e/attachment.htm>

More information about the TUHS mailing list