3 ms·

Just like there was never any point in keeping the first two digits of a year? Until Y2K approached and tons of code was still in production that hadn't ever be

Just like there was never any point in keeping the first two digits of a year? Until Y2K approached and tons of code was still in production that hadn't ever been expected to live that long. It cost companies a lot of money. Why make the same mistake again? I'm not saying optimizations like that are never worth it, but as a general rule the case would have to be made extremely well for me to ever sign off on it. And I bet in the huge majority of cases, the time cost of making that case would exceed the extra storage cost for using "unoptimized" data structures.

mprovost 14y ago
I can't find it at the moment but I remember reading a study showing that even with the cost of fixing Y2K issues it was still an economically sound decision to use two digit years given the historical cost of storage. In other words it was cheaper to fix the problem in 1999 than it would have been to buy enough mainframe storage in 1979 to store the extra two digits.
- glhaynes 14y ago
  Hah! Yeah, I could definitely see that being true. It was hasty of me to refer to that as "a mistake": as you say, that was a world in which every byte was several orders of magnitude more expensive. To save a similar amount of money on storage today of course it'd probably have to be tens or hundreds of kilobytes wasted per record. That kind of an optimization would very often still be worth looking into and optimizing for.
Dylan16807 14y ago
We're talking about a database here, not the code that processes a few records at a time. That code should be future proofed. But while the database design should be future proof, the exact settings don't have to be. Keep things properly isolated and nobody will ever know how many bits the database takes to store a value, and you can change it behind their backs with a single ALTER.
- glhaynes 14y ago
  you can change it behind their backs with a single ALTER If you're still there in 2038. And remember to do it.
  - katbyte 14y ago
    And someone hasn't written code based and tested on the 32bit date that then starts blowing (or even worse subtly making mistakes) up when you switch to 64bits...
    - Dylan16807 14y ago
      That code is going to work/break the same with or without the database being expanded. Only truly ridiculous code would depend on the fact that inserting a date in 2040 causes the database to reject that transaction. Anything else in the code involving dates should have unit tests but is entirely independent of the database.

mprovost 14y ago

I can't find it at the moment but I remember reading a study showing that even with the cost of fixing Y2K issues it was still an economically sound decision to use two digit years given the historical cost of storage. In other words it was cheaper to fix the problem in 1999 than it would have been to buy enough mainframe storage in 1979 to store the extra two digits.

glhaynes 14y ago
Hah! Yeah, I could definitely see that being true. It was hasty of me to refer to that as "a mistake": as you say, that was a world in which every byte was several orders of magnitude more expensive. To save a similar amount of money on storage today of course it'd probably have to be tens or hundreds of kilobytes wasted per record. That kind of an optimization would very often still be worth looking into and optimizing for.

Dylan16807 14y ago

We're talking about a database here, not the code that processes a few records at a time. That code should be future proofed. But while the database design should be future proof, the exact settings don't have to be. Keep things properly isolated and nobody will ever know how many bits the database takes to store a value, and you can change it behind their backs with a single ALTER.

glhaynes 14y ago
you can change it behind their backs with a single ALTER If you're still there in 2038. And remember to do it.
- katbyte 14y ago
  And someone hasn't written code based and tested on the 32bit date that then starts blowing (or even worse subtly making mistakes) up when you switch to 64bits...
  - Dylan16807 14y ago
    That code is going to work/break the same with or without the database being expanded. Only truly ridiculous code would depend on the fact that inserting a date in 2040 causes the database to reject that transaction. Anything else in the code involving dates should have unit tests but is entirely independent of the database.