• @rockSlayer
    link
    10511 months ago

    Well y275.8k will certainly be interesting

    • @danc4498
      link
      English
      39
      edit-2
      11 months ago

      They’ll work on a solution in the year 275,759

      • @[email protected]
        link
        fedilink
        811 months ago

        They’ll work on a solution in the year 275,759

        …written in ES5, Python 2 and mostly Rust++

    • @Quoth_The_Revan
      link
      311 months ago

      It’s fun how oddly close that year is with 0°C in Kelvin: 273.15. Seeing 275.8K just instantly brought me back to chemistry…

  • @[email protected]
    link
    fedilink
    7611 months ago

    Bold of you to assume no one will come up with a replacement date library rather than just getting rid of JS.

    • @[email protected]
      link
      fedilink
      6611 months ago

      It’s javascript. We’ll have gone through 275,760 new datetime libraries before then, it’ll be fine.

      • Thinker
        link
        211 months ago

        It’s not just a proposal, it’s already fully defined and almost completely implemented - I believe they’re just waiting on a standards update from ISO for time zone stuff.

  • katy ✨
    link
    fedilink
    5211 months ago

    slides £20 across the table make it end tomorrow

  • @xantoxis
    link
    4511 months ago

    Also means you can’t reference anything earlier than the late Pleistocene.

      • @NegativeInf
        link
        3011 months ago

        Sorry, that’s also wrong. The entire universe, in its current state, popped into existence last Tuesday. It’s been terribly inconvenient tho.

  • darcy
    link
    fedilink
    2511 months ago

    there goes my plans to build a time machine in javascript

  • @[email protected]
    link
    fedilink
    2411 months ago

    What people fail to see is that this is the largest date the API can store, not a magical cutoff date in the distant future.

    You could create a date today and send it to the API, and it could potentially crash it, or create a buffer overrun.

    • @[email protected]
      link
      fedilink
      811 months ago

      The definition of the Date object explicitly states that any attempt to set the internal timestamp to a value outside of the maximum range must result in it being set to “NaN”. If there’s an implementation out there that doesn’t do that, then the issue is with that implementation, not the standard.

  • @dadGPT
    link
    1711 months ago

    please hide this. this is how john connor defeats skynet.

  • Turun
    link
    fedilink
    1411 months ago

    That’s because this is the maximum integer that can be stored in a double precision floating point number without loss of precision, lol

  • Alien Nathan Edward
    link
    fedilink
    1411 months ago

    I’ve got a bunch of freeze dried food from my backpacking days. Who wants to jump in on a business selling Y275.76K Survival Kits?

    • @Wogi
      link
      211 months ago

      That will be a Saturday

      • @[email protected]
        link
        fedilink
        111 months ago

        it may or may not be a monday - probably won’t. it will be monday based on the (4000 | year) => !(leap year) rule, but by the year 275000 the difference will be so big that i am pretty sure people will make more rules to solve that.

    • SuperJetShoes
      link
      611 months ago

      This will be a tough one to fix. There must be millions upon millions of embedded systems out there with 16-bit epoch burned in.

      They’ll all be much tougher to find than “YEAR PIC(99)” in COBOL was.

      Y2K wasn’t a problem because thousands upon thousands of programmers worked on it well in advance (including myself) we had source code and plenty of static analysis tools, often homegrown.

      The 2038 bugs are already out there…in the wild…their source code nothing but a distant dream.