• bvs23bkv33 (unregistered)

    year 2048 would be good

  • Hal (unregistered)

    Limits aside this seems like a bad trade. Had he just allocated a full byte of memory rather than a nibble he could have a 256 years before a date rollover problem. There is basically non-chance any of these machines will be in use after 256 years! There simply had to be a better place to squeeze that nibble from; no matter how tiny the system memory was.

  • my name is missing (unregistered)

    This comment was posted in the year 1970.

  • JJ (unregistered) in reply to Hal

    It's always easy to nitpick the systems other people develop. But you never know what he had to do to get that extra nibble. Might be, in his situation, you would've done the same or maybe even worse.

  • (nodebb)

    After this, Encore’s company released upgraded version of the system which contained a GPS receiver, so that it could set its date based on that,

    Except (knowing how old some of these stories get) that probably broke last August...

    https://en.wikipedia.org/wiki/GPS_Week_Number_Rollover

  • P. Wolff (unregistered) in reply to Hal

    There is basically non-chance any of these machines will be in use after 256 years!

    This was irony, I hope? I mean, the hardware would be obsolete, maybe, but the software?

    Btw, I conclude you're younger than 0x38 years, or you'd know about the cost of a nibble back then. Hint: programs written in assembly were reviewed in machine code to save half a dozen bytes.

  • Vaclav Blazek (google)

    As anyone messing with electronics since childhood I still struggling not to read 2K15 as 2150.

  • (nodebb)

    In 12 years we're all dead from global warming, so the author doesn't need to worry.

  • (nodebb)

    [an] upgraded version of the system which contained a GPS receiver, so that it could set its date based on that

    Nut, meet Sledgehammer.

  • Bruce W (unregistered)

    "Everybody loves Bluetooth!" - Leonard Hofstadter

  • T. E. (unregistered)

    P. Wolff wrote "Btw, I conclude you're younger than 0x38 years, or you'd know about the cost of a nibble back then."

    However much effort you put into delaying the hurt, there comes a time when getting another nibble of RAM costs you a whole increment of RAM. This might mean, buying a more expensive memory chip which gives you some bytes; it might mean adding a memory chip to give you some bytes; it might mean buying (and finding room for) eight or nine (You don't really trust this new-fangled semiconductor memory, do you?) 1-bit wide memory chips; it might mean changing up to a processor with a bigger integrated RAM. If your processor already has the largest offered integrated RAM, your options start to be unpleasant.

    Aside: Being considerably older than 0x38 years, I easily get confused about the order of magnitude of attached storage. I remember kilobytes, megabytes, gigabytes, and I now have terabytes. What is the unit this week? I am giving up, and shall henceforth talk about lotsabytes.

  • John (unregistered)

    My company's products relied heavily on GPS way back then, and we had W1K eve party on August 21, 1999 to celebrate the rollover. Our systems rode through it with no issue.

    That was an embedded product that also used wireless communication, and I made all kinds of nasty bit encoding compromises to save transmission bytes, but time keeping was not one of those.

  • sizer99 (google)

    'The engineer who originally designed the device had a clever solution to storing dates.'

    Yeah, this is usually the problem. 'Clevar'ness. I've been there, I learned my lesson, it's never worth it. I will guarantee that their EEPROM was never so limited that it was worth saving 4 bits compared to the nightmare this has caused.

  • Joe (unregistered)

    2038!

  • ZB (unregistered)

    Sorry, I couldn't get past there being a person named "Encore".

  • Fernando (unregistered)

    And that GPS receiver has its own year-window problem. The GPSr in my 2011 Jeep has no idea what the date is.

  • (nodebb) in reply to T. E.

    Petabytes.

    When you get involved with enterprise wide data mining, we are talking about petabytes (PB) for non-trivial sized enterprises.

    E.G., ten years ago, Intel had 18 PB of enterprise data it managed - I have no idea how much they have now, but I would bet it is at least double that. If data growth followed Moore's law, it could be 100-200 PBs.

  • Jens Kuehnel (unregistered)

    y2k20 Problem with Red Hat Satellite 6: https://bugzilla.redhat.com/show_bug.cgi?id=1789654

    Classic. Using a python module that uses only two digit year, everything > 50 => 19XX. everthing < 50 => 20xx. Tool creates a Certificat with 30 Year lifetime. Crashes with Certs created after 1.1.2020. Bonus-Point: Problem was fixed upstream 2 years ago: https://github.com/candlepin/candlepin/blame/5b87865f304555c112982af4fbc83a1c463d37b2/server/src/main/java/org/candlepin/model/UeberCertificateGenerator.java#L263

    CU Jens

  • (nodebb) in reply to P. Wolff

    being 0x3f years old, 360/370 assembler was one of my most used languages.

  • Olivier (unregistered)

    Y2K15... While it makes sense to speak of Y2K, it saves a couple of characters, I find Y2K15 the stupidest notation ever: it saves nothing, it is less readable and needs more effort for our brain to interpret because it is a combination of characters types while 2015 is a straightforward number.

    Don't wonder why computer people are considered as weirdoes when they keep on using such stupid notations.

  • (nodebb)

    Not to mention that the bug hit on the rollover to 2016, not 2015. Unless the details in the story were simplified and the 16-bit rollover did hit them in 2015, it should be Y2K16 instead.

  • Foo AKA Fooo (unregistered) in reply to ZB

    Don't you know that in the US, corporations are persons? But this is no politics WTF site.

  • löchlein deluxe (unregistered)

    Ah yes, a sibling of the "no odd seconds" timestamp.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to sizer99

    I will guarantee that their EEPROM was never so limited that it was worth saving 4 bits compared to the nightmare this has caused.

    Except that the 4 bits saved wasn't in the EEPROM, it was in every reference to a date in RAM.

  • Zero (unregistered) in reply to Olivier

    Y2K refers more to the rollover problem associated with the year 2000, rather than the year 2000 itself. Just the word Y2K is enough to convey the problem; the word(s) "two thousand" or the figure 2000 is not sufficient to do that. The same association tells us immediately that Y2K15 is about some kind of rollover problem like we had in 2000 but now it is about 2015. Just saying 2015 doesn't do that. 2015. See? Y2K15. See? See? See what happened?

  • doubting_poster (unregistered)

    " It feels like date issues are turning into a sports game franchise: new releases of the same thing every year." So apt! For those not in the know, NBA2020 stopped working when the year ticked over into 2020. It's so meta, the meta has its own meta.

  • Game Developer (unregistered)

    "Every few years, the service tech could bring an EEPROM progammer device"

    Now that's what I call a progammer move!

Leave a comment on “Y2K15”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article