– By Arunabh Hazarika
I started my career in the software industry working on a Y2k project, way back in 1997, which seems like a lifetime ago. The project involved fixing COBOL programs and OS1100 ECL scripts running on Unisys main-frames, for Y2k bugs. For those not familiar with the Y2k problem, it was a really big deal back then, with apocalyptic musings by serious-looking reporters of how the world was going to end at the stroke of midnight of Dec 31, 1999 (or January 1, 2000, depending on your perspective) and how human-kind, which had come to depend so much on computers would be rudely pushed back to the stone-age by the inexorable march of time.
The problem was this. Engineers who developed software applications back in the 1970s did not anticipate them to still be in service 25-odd years later. Back then storage was expensive. So they skimped a bit by storing only the last two digits of the year when storing a date. Now, this would work fine for time difference calculations for dates all within the same century. However, come Jan 01, 2000, someone born on Jan 01, 1972, would suddenly be -72 years old. That would be a problem, most would say and I leave it to your imagination how this kind of miscalculation would impact things.
We developed some rudimentary tools that ran tests against the COBOL programs and flagged date calculations that were off. However, it still required a human engineer to parse the code, verify the bug and fix the date storage variable and any code that involved it. The process was laborious and mind-numbingly dull. But for a fresh out-of-college engineer, the process taught me a lot about programming patterns and techniques. The folks who built these systems back in the ’70s were every bit as smart as we are now and in my personal opinion, smarter – they did not have any of the tools we use now for programming.
So, why deja-vu all over again? 03:14:07 UTC on January 19, 2038. On that day, at that time, clocks on 32-bit systems that store system time in 32-bit signed integers will overflow. The system clock time will suddenly become negative. This time the problem is deeper. It is a hardware- and OS-level problem. Some embedded operating systems are still 32-bit and do store the system time in 32-bit signed integers. Moreover, there are quite possibly applications written in languages that do not run in a managed runtime, or run “closer to the metal”, where the developer used a 32-bit signed integer to store time and has been working fine all these years. Until the date above. The problem is especially prevalent for applications written in C, where the time_t type is defined as a signed 32-bit integer on 32-bit systems.
So, what to do? First, move to a 64-bit system, where time_t is a 64-bit long. However, that is not all. Most C compilers will be silent where a variable of type time_t is set to another variable of type int32_t (a C standard library defined 32-bit signed integer). So even if recompiled on a 64-bit system, the compilation will succeed. If you do not have tests that specifically test for dates beyond the Y038 date, your tests will still pass until the date above, where calculations involving the current system time will blow up – even on a 64-bit machine. So, second, write tests that specifically test for the Y038 problem and run them. You may be surprised by what you find.
At PositiveEdge, we pride ourselves on delivering scalable, reliable and performant applications, no matter what the tech stack is. Our obsessive focus on testing what we build has allowed us to maintain an enviable record 300+ implementations on Microsoft Dynamics Sales Hub, Service Hub, Business Central and Power Automate platforms.