Hacker News new | ask | show | jobs
by davengh 2291 days ago
When 5MB disk storage system is the size of a small car and costs $50k, you fight for bytes. Or if your data is stored on magnetic tapes and reading in a dataset can be costed by the kilobyte, takes minutes per megabyte, and requires a million dollar's worth of equipment and dedicated staff, you fight for every byte.

The phone I carry today is hundreds or thousands of times more powerful than the $5,000,000 mainframe I was working around Y2K and the apps on it - most delivered freely - make it far more capable than the raw processing power difference would indicate.

1 comments

If you are fighting for bytes then storing dates as "DD-MM-YY" strings is very inefficient, as you are wasting a factor 4X on storage compared to just storing the days since 1900 as a 2-byte integer. I understand that storage used to be expensive, but I don't understand where the two-digit year comes into play as I can't envision an efficient storage mechanism that is limited to exactly the years 1900-1999.
You need also to have the code to do the conversion. If you store, in a byte, the years since 1900 (or 1970) then every time you load and/or process a date to be displayed you need to add 1900 (or 1970) and then convert from int to str which takes time (machines were slow) and code.

And the code takes space.

You may think the space is trivial, but I remember working for nearly two weeks on a commercial system to save around 15 bytes on a system, and it was worth it.

Then the culture was embedded ... you worked to save bytes, and didn't do things that would cost more bytes. And the systems worked, and didn't need updated, so they persisted.

BCD (Binary-coded decimal) comes to mind; which can store values 0-99 in one byte and with native support in older CPUs.
One of my tasks for Y2K prep was to modify an in-house-developed record-based "database" to accommodate a the century change. Originally developed in the '60s the year had originally been a single digit because everyone thought commercial DBMS' would be viable in few years so there would be a replacement before the decade rolled over. :-| They'd grafted decade handling into the thing before I got there so it could survive the '70s because they had a lot of expensive data in various file sets that contained the data. Converting to a commercial database was expensive and represented a huge business risk, so...
If you have eight bit bytes, you would of course store these as three two digit BCD numbers requiring one byte each, and need no conversion logic. (The code for printing BCD numbers is already there, because you need it to print amounts of money anyway).