Last time this came up, I ran the numbers and the cost of the RAM saved per date stored was hundreds of dollars. Not per computer, or per program, but per date. Comparing total memory sizes doesn't tell the whole story, because RAM for a whole machine is so much cheaper now.
Spending that much money on storing "19" just so your code keeps working in the unlikely event that it's still in use 3+ decades into the future isn't a good tradeoff. Obviously things are different now.
Excellent point. Yeah, the machines my dad started on had magnetic core memory [1]. Each bit was a little metal donut with hand-wound wiring.
And in some ways, even "hundreds of dollars per date" doesn't quite convey it. These machines were rare and fiendishly expensive. In 2017 dollars, they started at $1M and went up rapidly from there. Getting more memory wasn't a quick trip to Fry's; even if you could afford it and it was technically possible, it was a long negotiation and industrial installation.
Another constraint that we forget about is the physicality of storage. Every 80 columns was a whole new punch card. That's a really big incentive to keep your records under 80 characters. Each one of those characters took time to punch. Each new card required physical motion to write and read, and space to store.
It really was a different world. I think a lot of programmers don't understand just how different it was (I barely do), and don't realize that modern principles like programmer time being more expensive than computer time are not universal truths about computing, but are just observations of how things are in recent decades.
The interesting thing about this from an engineering point of view is, you quietly pass a threshold where the clever hack which was worthwhile becomes literally more trouble than it is worth. When that happens is a multivariate problem that we couldn't truly predict at the time of the code's creation. (and when it happens, there might not even be anyone on the payroll thinking about it)
You're calculating what it would cost to store a string representation of a date. Which is silly. You should always convert to a timestamp for storage. You can cram way more info into a single integer than you can with a base 10 string. And the bonus is you verify the date's correctness before storing.
Even a 32-bit int could hold 11 million years worth of dates. And if your software is used for longer than that, you can just change it to a 64-bit long and have software that will outlast the sun.
Silly or not, that's the reality of punch card based technology (BCDIC later extended to EBCDIC). Punch cards pre-date electronic computers, and making a relay tabulator set-up working with binary formats is impractical.
As computer hardware grew out of that, it maintained much of the legacy, down to hardware data paths and specialized processor instructions. It was more than a programming convention.
That was the right choice for the era. As mikeash points out, your approach takes more bits and more CPU cycles. But it also takes a computer to decode. Any programmer can look at a punch card, a hex dump, or even blinkenlights and read BCD. Decoding a 32-bit int for the date takes special code. Which you have to make sure to manually include in your program, the size of which you are already struggling to keep under machine limits.
Systems from this era were probably using BCD rather than base-10 strings. A BCD date would take up 24 bits.
Running a complicated date routine to convert to/from 32-bit timestamps would also have cost a huge amount. These machines had speeds measured in thousands of operations per second, and the division operations needed to do that sort of date work would take ages, relatively speaking. All on a machine that cost dozens of times the average yearly wage at the time, and accordingly needed to get as much work done as possible in order to earn its keep.
Spending that much money on storing "19" just so your code keeps working in the unlikely event that it's still in use 3+ decades into the future isn't a good tradeoff. Obviously things are different now.