• @rockSlayer
    link
    1051 year ago

    Well y275.8k will certainly be interesting

    • @danc4498
      link
      English
      39
      edit-2
      1 year ago

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

    • @Quoth_The_Revan
      link
      31 year 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
    761 year 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
      661 year ago

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

      • Thinker
        link
        21 year 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.

  • @xantoxis
    link
    451 year ago

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

      • @NegativeInf
        link
        301 year 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
    251 year ago

    there goes my plans to build a time machine in javascript

  • @[email protected]
    link
    fedilink
    241 year 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
      81 year 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
    171 year ago

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

  • Turun
    link
    fedilink
    141 year 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
    141 year 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
      21 year ago

      That will be a Saturday

      • @[email protected]
        link
        fedilink
        11 year 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
      61 year 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.