A lot of older software counts time as the number of seconds since 1 January 1970, stored in a 32-bit signed integer. That runs out at 03:14 UTC on 19 January 2038, and when it does the number goes negative - so the system believes it is 1901. Anything that compares dates then behaves unpredictably: certificates look invalid, schedules never fire, logs sort backwards.

Modern hardware and operating systems have used 64-bit time for years, which pushes the problem roughly 292 billion years out. Your phone, laptop, and any cloud service you use are not the issue. This is worth stating clearly, because the internet is already producing alarming content about it.

The real exposure sits in three places: industrial and building controllers, embedded devices nobody thinks of as computers, and bespoke software written against old libraries. In practice that means plant rooms, access control panels, CCTV recorders, medication trolleys, telematics units and the finance system a company had written in 2009.

You do not need a project. You need an inventory, and a question to ask suppliers at renewal: is this system 64-bit time safe, and if not, what is the plan? Asking now, twelve years out, costs a sentence in an email. Asking in 2036 costs whatever the supplier decides to charge you.

Our own position: we flag any device or system on your register that is past supplier support, and we will start surfacing 2038 exposure explicitly as suppliers begin publishing statements. It is a good example of a risk that is genuinely real, genuinely distant, and genuinely cheap to handle early.