Attention programmers!
Good logic lasts forever.
Many of you were not in the programming business in the 1980s. Back then, we realized that Y2K was on its way and there was a lot of code that would break with dates beyond 1999-Dec-31.
At the time we were looking to save storage - heck, I supported systems that stored the year in 4 bits, because it was a huge memory saver, and 16 years of operation was a long time. We simply expected that our systems would be retired before then.
But come the 1990's, we realized we were still running programs written in the 1960s, and someone would have to address all of the date calculation problems.
Turn the clock ahead to today and we see that in less than 25 years the classic 32-bit Unix clock will turn over. And the storage problem no longer exists like it once did. In the past we often tried to squeeze in a full Gregorian date (Y-M-D) into 15 or fewer bits. Today, using 24 or 32 more bits to store a Gregorian date seem completely reasonable and will greatly outlast our era.
Best practice demands that our code of today will work perfectly with dates into and beyond 2038. As programming matures as a business, we should be validating clocks and times and dates well into the future, at least beyond 2101.
Are you signing a contract for software services? Demand proper testing for this problem today. Code easily lasts for more than 25 years, and so not demanding proper date handling behavior is irresponsible and a dereliction of your professional obligations. Period.
Our software will be running in 80+ years into the future?
Why not? Buildings and bridges are designed and maintained to last for centuries... we hope. Logic lasts forever; why dispose of otherwise good work?
Good logic lasts forever.
Many of you were not in the programming business in the 1980s. Back then, we realized that Y2K was on its way and there was a lot of code that would break with dates beyond 1999-Dec-31.
At the time we were looking to save storage - heck, I supported systems that stored the year in 4 bits, because it was a huge memory saver, and 16 years of operation was a long time. We simply expected that our systems would be retired before then.
But come the 1990's, we realized we were still running programs written in the 1960s, and someone would have to address all of the date calculation problems.
Turn the clock ahead to today and we see that in less than 25 years the classic 32-bit Unix clock will turn over. And the storage problem no longer exists like it once did. In the past we often tried to squeeze in a full Gregorian date (Y-M-D) into 15 or fewer bits. Today, using 24 or 32 more bits to store a Gregorian date seem completely reasonable and will greatly outlast our era.
Best practice demands that our code of today will work perfectly with dates into and beyond 2038. As programming matures as a business, we should be validating clocks and times and dates well into the future, at least beyond 2101.
Are you signing a contract for software services? Demand proper testing for this problem today. Code easily lasts for more than 25 years, and so not demanding proper date handling behavior is irresponsible and a dereliction of your professional obligations. Period.
Our software will be running in 80+ years into the future?
Why not? Buildings and bridges are designed and maintained to last for centuries... we hope. Logic lasts forever; why dispose of otherwise good work?