10 ms·

> I don't know about now but it wouldn't shock me We'll be up for a few Y2K bugs at the start of every decade because 'year += year < n ? 2000 : 1900' was such

> I don't know about now but it wouldn't shock me We'll be up for a few Y2K bugs at the start of every decade because 'year += year < n ? 2000 : 1900' was such an easy workaround, for n=20,30,40,... https://www.pymnts.com/news/payment-methods/2020/new-years-bug-takes-nyc-parking-meters-offline/ https://www.pymnts.com/news/payment-methods/2020/new-years-b...

LeifCarrotson 7y ago
There's less cause to use small data sizes for timestamps and date codes now. Storage has grown by orders of magnitude, the idea that a numeric data type would only be large enough to store a 2-digit year or that you would want to save disk space by abbreviating an extra 2 letters is foreign to a lot of new developers. And the 20-year-old systems are slowly dissapearing...
- bluGill 7y ago
  More importantly we have figured out algorithms for time that account for timezone, daylight savings time, different calendar systems, and probably something else I'm not aware of. These all work by counting seconds since a fixed date. Note that the algorithms were known since at least the late 1960s. Storage space even then shouldn't have been enough of a concern. However people still screw it up all the time.
  - LeifCarrotson 7y ago
    And in that vein, no one (sane) is writing their own date libraries anymore, there's no reason to try to customize that for your application.
  - davismwfl 7y ago
    This is the accurate point. We had epoch date tracking since the 1960s or so and the coding of a two digit year was out of laziness and convenience in most cases. And not bashing anyone, but most of the systems I saw using the lazy method were more business systems where there wasn't thoughtful engineering a lot of the time, but more just get it done. Those two don't have to be mutually exclusive IMO, but in the 70s/80's it seems a lot of the time it was, simply because IMO we had predominately really two classes of developers, scientific and business where business devs took less of an engineering mindset and more get it done in a specific timeframe so they "hacked" it out. Plus it was new, so stuff happens. Sadly this stuff still goes on today, just in slightly different ways. Data type and data structure choices are critical, and it isn't as important to me that someone know how to write an algorithm for a RB-tree (or pick your DS), but it is critical an engineer knows which data structure/type to choose for specific use cases. This is one of my biggest complaints with the way a lot of engineering interviews are structured today, they want you to regurgitate known algorithms which is a waste of time and personal memory, find out if the person knows when they'd use a specific data structure and why the rest is easily researched. I mention this because to me the fundamental flaw of the y2k problem was one of data structure and data type choice.
  - fanf2 7y ago
    Seconds since the epoch doesn’t work for times in the future. Consider a contract that will terminate at 2025-02-28 12:00 in New York: will that be -05:00 or -04:00? It could change.
- mytherin 7y ago
  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
- davengh 7y ago
  >> And the 20-year-old systems are slowly dissapearing There's still COBOL code out there running core business systems that's older than I am, and I'm closer to 60 than I am to 50.
mark-r 7y ago
There was a related story here on HN recently. A system was assuming a 101-year-old was actually only 1 year old, presumably because of 2 digit arithmetic. https://news.ycombinator.com/item?id=22356373 https://news.ycombinator.com/item?id=22356373
- dehrmann 7y ago
  They were a modulo 100 1-year-old. Modulo 100 ages: feature, not a bug.
sharpy 7y ago
One system I worked on showed the date as year 3900, because the function for getting current year would return 2 digit for year < 2000, and full 4 digit for >= 2000. So the code did 1900 + GetYear(). Replaced it with just calling GetFullYear() or something like that.

LeifCarrotson 7y ago

There's less cause to use small data sizes for timestamps and date codes now. Storage has grown by orders of magnitude, the idea that a numeric data type would only be large enough to store a 2-digit year or that you would want to save disk space by abbreviating an extra 2 letters is foreign to a lot of new developers. And the 20-year-old systems are slowly dissapearing...

bluGill 7y ago
More importantly we have figured out algorithms for time that account for timezone, daylight savings time, different calendar systems, and probably something else I'm not aware of. These all work by counting seconds since a fixed date. Note that the algorithms were known since at least the late 1960s. Storage space even then shouldn't have been enough of a concern. However people still screw it up all the time.
- LeifCarrotson 7y ago
  And in that vein, no one (sane) is writing their own date libraries anymore, there's no reason to try to customize that for your application.
- davismwfl 7y ago
  This is the accurate point. We had epoch date tracking since the 1960s or so and the coding of a two digit year was out of laziness and convenience in most cases. And not bashing anyone, but most of the systems I saw using the lazy method were more business systems where there wasn't thoughtful engineering a lot of the time, but more just get it done. Those two don't have to be mutually exclusive IMO, but in the 70s/80's it seems a lot of the time it was, simply because IMO we had predominately really two classes of developers, scientific and business where business devs took less of an engineering mindset and more get it done in a specific timeframe so they "hacked" it out. Plus it was new, so stuff happens. Sadly this stuff still goes on today, just in slightly different ways. Data type and data structure choices are critical, and it isn't as important to me that someone know how to write an algorithm for a RB-tree (or pick your DS), but it is critical an engineer knows which data structure/type to choose for specific use cases. This is one of my biggest complaints with the way a lot of engineering interviews are structured today, they want you to regurgitate known algorithms which is a waste of time and personal memory, find out if the person knows when they'd use a specific data structure and why the rest is easily researched. I mention this because to me the fundamental flaw of the y2k problem was one of data structure and data type choice.
- fanf2 7y ago
  Seconds since the epoch doesn’t work for times in the future. Consider a contract that will terminate at 2025-02-28 12:00 in New York: will that be -05:00 or -04:00? It could change.
mytherin 7y ago
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
davengh 7y ago
>> And the 20-year-old systems are slowly dissapearing There's still COBOL code out there running core business systems that's older than I am, and I'm closer to 60 than I am to 50.

mark-r 7y ago

There was a related story here on HN recently. A system was assuming a 101-year-old was actually only 1 year old, presumably because of 2 digit arithmetic. https://news.ycombinator.com/item?id=22356373 https://news.ycombinator.com/item?id=22356373

dehrmann 7y ago
They were a modulo 100 1-year-old. Modulo 100 ages: feature, not a bug.

sharpy 7y ago

One system I worked on showed the date as year 3900, because the function for getting current year would return 2 digit for year < 2000, and full 4 digit for >= 2000. So the code did 1900 + GetYear(). Replaced it with just calling GetFullYear() or something like that.