Time recording in IT: The 2038 problem

Table of contents

No Bugs Knowledge

The clock is ticking, the bugs are crawling: from punch cards and 32-bit to the 2038 error in IT time recording

Hello Bugbuster friends! Today we're going on a fascinating journey through the vastness of computer time. From the mysterious age of punch cards to the Y2K bug and the 2038 error in the computer timestamp, we explore the historic turning points of time measurement in the digital world.

Why is time measurement so important in IT? The answer lies in the precision, efficiency and synchronization that it brings to systems and processes. Every smooth flow of processes, every transaction of money, every event in IT is based on error-free time recording.

Or simply explained: So that your vacation request is entered at the right time.

The era of punched cards: when we punched bits on perforated paper

Let's travel back in time to the early days of computing, when punched cards were the language of data transmission. On these perforated cards, information was encoded through holes - a simple but ingenious form of data storage. This was the heart of the original bit limitation, as each card could only carry a limited amount of information. This meant that only the last two digits of the year were recorded on the perforated cards, which was a clever trick to save space.

1998 = 98, 1999 = 99. What about 2000 = 00 or is it 1900?

The Y2K problem: The Y2K bug is spreading (Century Date Change)

Now we move on to the exciting year 2000, when the computer world was under the spell of the Y2K problem. Here, the original bit limitation of punched cards came up against more modern systems that stored the year as a four-digit number. But the past sent its regards: many of these systems were unable to recognize the century limit, which led to the year 2000 being interpreted as the year 1900. Like clockwork that misses its own time, computers found themselves in a dilemma.

Unix time was introduced. This time measurement represents the time in seconds, retroactively since January 1, 1970, 00:00 UTC, as an integer in 32 or 64 bits.

We can see that no matter how brilliant an idea may be, it can cause unforeseeable problems in the future.

The 2012 error: 23:59:60?

Shortly afterwards, we enter the year 2012 and encounter a small bug called the “leap second”.

One day has 86,400 atomic seconds in Coordinated Universal Time (UTC). In order to ensure synchronization with the Earth's rotation, the IERS (International Earth Rotation and Reference Systems Service) determines when we carry out +1 second synchronization.

Why are we introducing this leap second? In short: the Earth's rotation is not constant and is changed by the moon, volcanoes and other external influences.

This adjustment was not introduced because it is technically necessary, but because the 24-hour day/night change always has 86,400 seconds.

This seemingly inconspicuous event, which added an extra second to December 31, revealed surprising vulnerabilities in computer systems and software applications.

Some systems were unable to process the additional second correctly, which led to unexpected failures or problems. This was due to the fact that some software developers had not fully considered the effects of a leap second.

But doesn't the leap second occur more often?

Yes - it was added in 2005, 2008, 2012, 2015 and 2016 and should also have been taken into account by the systems here. But due to increasingly complex programs, it can easily happen that something like this is overlooked.

This aspect was the banks' undoing in 2012, with the result that no one was able to withdraw money from ATMs.

The 2038 problem: when timestamps drown in bits

And finally, we move into the future, where the 2038 bug awaits us. In this era, 32-bit systems once again collide with time and reach their limit in 2038.

What does that mean?

The problem occurs when this time counter no longer has enough bits to display the seconds since the start date. In 2038, the number of seconds will reach 2,147,483,647, which can no longer be represented in a 32-bit representation. If the system is not converted to a 64-bit representation or another solution, the time counter will be reset to zero, which can lead to malfunctions and unexpected behavior in many applications and systems.

This could lead to a number of problems, such as:

  • Timestamps in databases could become invalid.
  • Planned tasks and time controls could fail.
  • Systems that use security certificates could end up in a faulty state.
  • Log files and time stamps in applications could become unreliable.
  • Log files and timestamps in applications could become unreliable and network protocols based on correct time counters could fail.

Final thoughts: A journey through the history of IT

Our journey through the age of computerized timekeeping shows how the past shapes the future and how the limitations of bits affect the way we measure time. From punch cards to modern systems, the original bit constraint connects us in fascinating ways. As technology advances, it's exciting to see how our time traveling machines evolve and explore new horizons. Let's delve into the depths of computer time and look forward to the stories it still has in store for us!

Since we not only have universal time (UT), but also astronomical time (local sidereal time).

A little task for the IT geeks to think about:

How do you synchronize time when travelling to the moon and Mars? The moon moves around the earth at approx. 3700 km/h. Seen from Earth, this is “relatively” fast. You know where I'm going - Einstein sends his regards.