Your systems have an expiry date

On Tuesday, 19 January 2038, at 03:14:07 UTC the Unix timestamp runs out of space. Countless systems count time as seconds since 1970 and store that number in 32 bits. One second later, those systems believe it is 13 December 1901.

This is not a single bug that a single update fixes. It is spread across operating systems, databases, file formats, network protocols, embedded devices and decades of business software, including systems your company depends on but doesn’t control.

It is already causing failures

You don’t have to wait until 2038. Every system that calculates dates in the future hits the limit early:

• contracts, loans, leases and warranties running past 2038
• subscriptions, licences and certificates with long validity
• pension, insurance and depreciation calculations
• devices and data that must be retained or supported for 10+ years

Depending on the system, such dates are rejected, silently replaced by zero, or turned into nonsense. Often nobody notices until a customer, an auditor or a court does.

Why this takes years, not weeks

From the outside, the fix sounds simple: “use 64 bits”. In practice, every organization that has tried it finds the same obstacles:

• Nobody has the full inventory. 32-bit time hides in custom code, third-party libraries, database schemas, interfaces to partners, file archives and the firmware of devices nobody thinks of as computers.
• Custom protocols were never reviewed. Standard protocols have specifications and standards bodies watching them. In-house protocols, from game networking to industrial and payment systems, usually have neither: their only documentation is the code, and nobody has checked them for 2038.
• Fixing code isn’t enough. Stored data, backups, exchange formats and database columns have to be migrated too, often on live production systems that can’t stop.
• Both ends have to change. An interface is only fixed when every system that uses it is fixed, including those of suppliers, customers and partners.
• Hardware lives longer than you think. Machines, vehicles, building technology, medical and payment devices run for 15 to 30 years. Equipment bought today will still be in use in 2038.
• Vendors set the pace. Where you depend on a vendor’s firmware or software, you need their roadmap, contracts and confirmation, and those take time.
• Regulated systems need re-testing and re-approval. In finance, healthcare, energy, automotive and industry, every change goes through validation.
• Budgets and release cycles are slow. A change that needs planning, funding, testing and rollout in several systems easily spans several fiscal years.

Y2K kept organizations busy for years, and it was a simpler problem with a hard, visible deadline. The 2038 problem is deeper in the technology stack and far less visible. Organizations that start in 2035 will be competing for the same few specialists as everyone else.

What to do now

1. Assess your exposure. Which systems, data and interfaces handle dates, and which of them use 32-bit time?
2. Prioritize by business risk. What breaks first, what is critical, and where are dates beyond 2038 already in use?
3. Plan the migration. Code, data, interfaces, vendors and hardware, with a realistic roadmap and budget.
4. Add it to procurement. Make “works correctly beyond 2038” a requirement for every new system and device you buy.
5. Test. Run critical systems with the clock set beyond 2038 before reality does it for you.

Find the right partner for your migration

A 2038 migration needs people who know your kind of systems: embedded firmware, mainframes, databases, industrial protocols, or software in a regulated industry. Finding them is hard, and it will get harder as the deadline gets closer.

We connect businesses with experienced partners for exactly these projects:

1. Tell us about your situation: your industry, the kinds of systems involved and your timeline.
2. We find suitable partners with experience in your technology and industry.
3. You get introductions and decide who you want to work with.

Find a migration partner

Your contact: Dr. Steffen Weise · contact@unixtimestampexpires.com

Are you a provider? If you plan or carry out migrations like these and would like to be recommended, get in touch.

Want the technical background? Read why the timestamp expires and which systems are affected.