Bit of a departure from the norm today.
I spend a few months of 1999 working on a Y2K project that had… some issues, but eventually wound up being deployed before the New Year and was still working over a decade later.
Sadly, I know that it was still in use over a decade later because the company was involved in a massive public data breach and the system I worked on was also the one that the attackers used to get in.
In a feeble attempt at defense, our concern at the time was “can we still ship product on Jan 1 2000?” and not so much anything else.
Anyway, between that and the upcoming “You thought Y2K was an issue?” excitement we are all looking forward to on January 19th, 2038, I have a mild interest in how humans choose to encode dates in computer systems.
I think I have hit a new low point. I discovered today that one of the products I work on stores dates internally in the following format:
YY = Number of years since 1970, in hexadecimal.
MM = Month of the year. Also in hexadecimal. 0-indexed, so values from 00 (January) to 0B (December).
DD = Day of the month, in hexadecimal.
As an example, the upcoming summer solstice (June 21st, 2020) would be read “320515” which is just the most amazing way to make a date as impossible for a human to read as possible without obviously getting into obfuscation tactics.
In addition, if the goal was to save table space by avoiding using a 4-digit year, they should theoretically have dropped the leading 0 in Months unless we are worried that the world is going to add a few more months into the year at some point.
There are times I wonder whether we are actually employing human developers or not, and this puts a solid X mark in the “evidence our programming team is made of space aliens” column.
Anyway, sorry for the out-of-nowhere rant.