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:

YYMMDD

Where:

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.