4 ms·

Perhaps you could expand on this as I was not involved in Y2K myself. Storing dates with 2 digit years doesn't seem to make much sense as a storage saving mecha

Perhaps you could expand on this as I was not involved in Y2K myself. Storing dates with 2 digit years doesn't seem to make much sense as a storage saving mechanism for me. If you want to store only the year, why not store the years since 1900? That way in a single byte you can go all the way up until 2155. If you want to store it bit-aligned rather than byte-aligned why limit yourself to 00-99? 7 bits can store the year from 1900-2027. If you want to store day + month + year with a two digit year you have 365.25*100=36525~ options. A two byte value can store up until 65535 options, which can hold all days until 2079. If you are storing your dates as flat strings (DD-MM-YY or so) then you are already wasting such a large amount of bytes that "storage concerns" seem moot. You are already using 8 bytes to store a date that can be stored in 2 bytes, at that point why not use 10 bytes? String formatting and display seems more obviously affected to me than storage.

krallja 7y ago
> why not store the years since 1900 Most input systems were punch cards, which were designed to be fixed-length textual input directly from a user at a card punch machine. Teaching users how to map from “years since 1900” to the correct keys on the card punch is a lot more confusing and error prone than having the computer automatically convert from "71" to 1971.
- mytherin 7y ago
  That makes a lot more sense, but if it is just input then why not do the conversion of the string "71" to the efficient byte representation of 1971 when it is moved into the storage. If the computer can do a mapping of "71" -> 1971 then why can't it also do a mapping of "10-10-71" -> 26214 (days since 1900-01-01).
  - fhars 7y ago
    Then you would need another column on the card, and there are even fewer columns on a card than there are bytes in RAM.
  - krallja 7y ago
    The punched card, for a long time, _was_ the storage.
davengh 7y 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.
- mytherin 7y ago
  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.
  - ColinWright 7y ago
    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.
  - dezgeg 7y ago
    BCD (Binary-coded decimal) comes to mind; which can store values 0-99 in one byte and with native support in older CPUs.
    - davengh 7y ago
zwp 7y ago
This is a good question. I found a copy of Fujitsu COBOL 85 manual [1] (the next release was post y2k, in 2002) and was surprised to see that CURRENT-DATE, INTEGER-OF-DATE use 4-digit years. However some functions from that time (eg ACCEPT, p. 544) do use 2-digit years. I think you have it exactly right, it was about facilitating string formatting/display: ACCEPT took input from the terminal screen. (I think it is, approximately, gets() + strptime(), though I don't see any talk of error handling). Programmers probably just stuffed the result into a record before writing to DASD (disk), optimizing for programmer time and program complexity over storage. Perhaps 2-digit years for ACCEPT were an optimization for data entry workers? A modern z/OS COBOL guide [2] has 4-digit years throughout as far as I can see. Whilst I'm here, I'm also going to say: "VSAM", "PDS", TSO", "LRECL" and "ABEND" (just because I haven't heard those words for a quarter century and now I'm feeling nostalgic). [1] http://testa.roberta.free.fr/My%20Books/Mainframe/Fujitsu%20COBOL%20-%20Language%20Reference.pdf http://testa.roberta.free.fr/My%20Books/Mainframe/Fujitsu%20... [2] https://www.ibm.com/support/knowledgecenter/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlpsacce.htm https://www.ibm.com/support/knowledgecenter/SS6SG3_4.2.0/com...
- JackFr 7y ago
  What about "JCL" ? Those ABENDs don't just show up on their own.
mschaef 7y ago
> If you want to store only the year, why not store the years since 1900? That way in a single byte you can go all the way up until 2155. You're making an assumption in that statement that there's a byte and it's eight bits in length. This was not always true. Punch cards didn't really work that way, and fair number of CPU's didn't either. Early machines used various decimal systems and 6-bit characters were widespread also. This explains a bit of why the C language and descendants often have native support for Octal literals and Unix permissions are built around three bit groupings. On a personal note, even in the very early 90's, I also remember using a CDC machine (a descendant of Seymour Cray's 6600) that supported 60-bit words with 6-bit characters. Pressure to move to 64 bit words with 8-bit bytes resulted in dual mode design that could be booted either way.
- mcswell 7y ago
  CDC...if it was like the CDC system I worked on back in the early 80s, the 6-bit chars (64 distinct chars, including control chars) did not include lower case Latin. Our system was munged so that lower case alphabetic chars could be represented by prefixing a backslash. I wrote my dissertation on that system, and fortunately the editor I used displayed a backslashed char as lower case.
unilynx 7y ago
A whole byte for a year? What a waste in 1995 when you've got just 640KB for DOS, your code and your data. I looked up my old code. Shave off a bit of the year and: struct Date { unsigned day : 5; unsigned month : 4; unsigned year : 7; }; a full date in 16 bits. (well, in borland C++ 5 at least) and as it was an accounting application, working with the bitfields was so much nicer than ordinal days you would use nowadays. month and years was all you really cared about anyway when summarising data. in finance all months have 30 days anyway.
- C1sc0cat 7y ago
  the problem came from the 60's when memory was really expensive on mainframes and you had things like drum storage

krallja 7y ago

> why not store the years since 1900 Most input systems were punch cards, which were designed to be fixed-length textual input directly from a user at a card punch machine. Teaching users how to map from “years since 1900” to the correct keys on the card punch is a lot more confusing and error prone than having the computer automatically convert from "71" to 1971.

mytherin 7y ago
That makes a lot more sense, but if it is just input then why not do the conversion of the string "71" to the efficient byte representation of 1971 when it is moved into the storage. If the computer can do a mapping of "71" -> 1971 then why can't it also do a mapping of "10-10-71" -> 26214 (days since 1900-01-01).
- fhars 7y ago
  Then you would need another column on the card, and there are even fewer columns on a card than there are bytes in RAM.
- krallja 7y ago
  The punched card, for a long time, _was_ the storage.

davengh 7y 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.

mytherin 7y ago
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.
- ColinWright 7y ago
  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.
- dezgeg 7y ago
  BCD (Binary-coded decimal) comes to mind; which can store values 0-99 in one byte and with native support in older CPUs.
  - davengh 7y ago

zwp 7y ago

This is a good question. I found a copy of Fujitsu COBOL 85 manual [1] (the next release was post y2k, in 2002) and was surprised to see that CURRENT-DATE, INTEGER-OF-DATE use 4-digit years. However some functions from that time (eg ACCEPT, p. 544) do use 2-digit years. I think you have it exactly right, it was about facilitating string formatting/display: ACCEPT took input from the terminal screen. (I think it is, approximately, gets() + strptime(), though I don't see any talk of error handling). Programmers probably just stuffed the result into a record before writing to DASD (disk), optimizing for programmer time and program complexity over storage. Perhaps 2-digit years for ACCEPT were an optimization for data entry workers? A modern z/OS COBOL guide [2] has 4-digit years throughout as far as I can see. Whilst I'm here, I'm also going to say: "VSAM", "PDS", TSO", "LRECL" and "ABEND" (just because I haven't heard those words for a quarter century and now I'm feeling nostalgic). [1] http://testa.roberta.free.fr/My%20Books/Mainframe/Fujitsu%20COBOL%20-%20Language%20Reference.pdf http://testa.roberta.free.fr/My%20Books/Mainframe/Fujitsu%20... [2] https://www.ibm.com/support/knowledgecenter/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlpsacce.htm https://www.ibm.com/support/knowledgecenter/SS6SG3_4.2.0/com...

JackFr 7y ago
What about "JCL" ? Those ABENDs don't just show up on their own.

mschaef 7y ago

> If you want to store only the year, why not store the years since 1900? That way in a single byte you can go all the way up until 2155. You're making an assumption in that statement that there's a byte and it's eight bits in length. This was not always true. Punch cards didn't really work that way, and fair number of CPU's didn't either. Early machines used various decimal systems and 6-bit characters were widespread also. This explains a bit of why the C language and descendants often have native support for Octal literals and Unix permissions are built around three bit groupings. On a personal note, even in the very early 90's, I also remember using a CDC machine (a descendant of Seymour Cray's 6600) that supported 60-bit words with 6-bit characters. Pressure to move to 64 bit words with 8-bit bytes resulted in dual mode design that could be booted either way.

mcswell 7y ago
CDC...if it was like the CDC system I worked on back in the early 80s, the 6-bit chars (64 distinct chars, including control chars) did not include lower case Latin. Our system was munged so that lower case alphabetic chars could be represented by prefixing a backslash. I wrote my dissertation on that system, and fortunately the editor I used displayed a backslashed char as lower case.

unilynx 7y ago

A whole byte for a year? What a waste in 1995 when you've got just 640KB for DOS, your code and your data. I looked up my old code. Shave off a bit of the year and: struct Date { unsigned day : 5; unsigned month : 4; unsigned year : 7; }; a full date in 16 bits. (well, in borland C++ 5 at least) and as it was an accounting application, working with the bitfields was so much nicer than ordinal days you would use nowadays. month and years was all you really cared about anyway when summarising data. in finance all months have 30 days anyway.

C1sc0cat 7y ago
the problem came from the 60's when memory was really expensive on mainframes and you had things like drum storage