Categories
Software Testing

The Y2K bug in the year 2038

Do you remember how the world freaked out over the potential Y2K bug when the year was changing from 1999 to 2000? A large mitigation factor was a huge outsourcing effort to India and it helped to establish India as the global IT giant it is today. So when not many bugs eventuated it was a bit anti climatic. 


Globally; $308 billion dollars was spent on compliance and testing and it helped build more robust systems that survived the system crashes from the 9/11 terrorist attacks. 


Well the y2k bug would only impact systems that used 2 digits to represent the year, i.e. using the DDMMYY format to save on memory.

And the world updated this and their systems every where. Businesses did a pretty good job of patching that bug before it became an issue. Bugs still did come up but the world didn’t end.

Sometimes the fix was to push it out

Some fixes people implemented was to make 00 to 20 stand for 2000 and 2020 respectively. That’s only pushed out the problem and we’ve had some cases this year of this bug coming into effect. You can read more about this 2020 Y2K bug here.

There’s another bug for 2038

However did you know there is another Y2K bug scheduled for the year 2038? Basically the way our current 32 bit computer systems count time is the number of seconds since 1970. In the year 2038 we get a bit overflow issue and that counter resets to zero. This is more likely to impact cheap embedded systems with limited memory or old legacy systems.

If we switch to a 64 bit counter, our sun will explode before we get the same issue. It’s like going from ipV4 (we are already running out of ip addresses) to ipV6 for the internet.

IPv6 – Let the Sky Fall!

2038 might feel like a long way away but here’s a story about pension payments breaking in 2018 due to this bug (20 years before this bug is meant to occur):

Is your system at Risk?

So, are any of your legacy systems at risk? Do you think you’d have them migrated to cloud infrastructure before this issue occurs?

How about setting up a test environment that’s configured to be 6 months ahead of production? Would that give enough time to find and fix these issues when they occur?

Leave a Reply