Year 2038 Problem

What is the Year 2038 Problem you ask? A Wikipedia page entry has a good description.

On 19 January 2038 many computer clocks will reset to 14 December 1901 (not 1 January 1970, the epoch of zero, as some believe; as wrap-around for a signed integer reverts to -2^31).

Specifically on 19 January 2038 at 03:14:07 UTC (2:14pm Sydney/Melbourne, 1:14pm Brisbane, 1:44pm Adelaide, 11:14am Perth) these clocks will reset to represent 14 December 1901 6:45am (Sydney/Melbourne).

How Widespread is this?

Very widespread. It was common practice for a long time to compute dates and times using the 32-bit signed integer. With 32-bit computing being the norm for decades it was the simplest way to access/compute/store date and time.

Many mitigations are already in place. Modern operating systems now use 64-bit counters where they used to use 32-bit.

What is Technical Debt?

“Technical debt” is a widespread term to describe the cost that must be paid in the future to maintain a system.

Systems and applications implemented with 32-bit second counters were adequate for the time they were made. But such systems, if still in use, require updating - and that incurs a cost in labour and, potentially, hardware.

The Year 38 problem is one of technical debt coming due. One way or another it must be addressed. One way to view this is to admire the success of such code that is still in use today.

What We Do

We will conduct an audit of your systems to determine exposure to risk of the Year 2038 Problem.

Analysis will need to cover:

  • operating systems in use
  • data storage systems in use (e.g. databases)
  • custom organisation-specific code
  • third party applications
  • hardware in use (such as desk phones, wall clocks, displays)

There are steps involved:

  1. identifying potential systems at risk
  2. in-depth analysis of at-risk systems for references to time
  3. specifying mitigations - such as patching old software, proposed code changes, or migration to safer systems and software
  4. actioning mitigations
  5. testing

Types of Service

We offer two categories of service:

  1. pre-issue, and
  2. post-issue

Pre Issue

Where you engage us before you’ve experienced an outage, bug, or customer-affecting issue.

Post Issue

This is where you have noticed problems in date calculations already. Where customers have been directly affected - either in being given wrong dates, or been denied service because of date calculation errors.

We can engage post issue (also known as “firefighting”) but it is a considerably more costly exercise because of the urgency involved.

Why Contract Us to Help?

  • experience - with more than 25 years’ programming experience in C, having done date calculations in different timezones that change between daylight savings and standard - we provide experience
  • knowledge - this date issue centres around the use of the signed 32-bit integer type - having intimate familiarity with this data type affords us the knowledge we need to combat the issue

These date issues will largely stem from code written in C and Assembler. Scripting languages are not immune - indeed many high level languages will also be exposed to the issue as well.

And it isn’t just a software exercise. Your databases may have tables structured to store the date information as a signed 32-bit integer to save space or for ease of calculation.