• Jamablaya@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    56 minutes ago

    oh just start at 0000 again, signate that as 10,000. Files didn’t start until like 1979 anyways, and there can’t be many left, and even if it is a problem, now you have 2000 years to not worry about it.

  • BmeBenji@lemm.ee
    link
    fedilink
    arrow-up
    6
    ·
    2 hours ago

    We’re being short-sighted

    Tell that to the billionaires speed-running terraforming this planet into a barren wasteland.

    • dependencyinjection@discuss.tchncs.de
      link
      fedilink
      arrow-up
      16
      arrow-down
      6
      ·
      4 hours ago

      Seems hyperbolic to assume we will be extinct by 9999.

      Sure we’re heading for a climate crisis, but I don’t think all humans will be dead; Just the poorest.

      • Donkter@lemmy.world
        link
        fedilink
        arrow-up
        21
        arrow-down
        1
        ·
        3 hours ago

        That has forever been the fallacy.

        The poor won’t die in the apocalypse leaving only the rich behind. The poor will die, and the rich will be faced with the harsh reality that they needed an army of poor working under them to sustain themselves, leading them to all die within the generation.

  • chetradley@lemm.ee
    link
    fedilink
    arrow-up
    30
    arrow-down
    1
    ·
    5 hours ago

    In 9999, this meme will be problematic because it assumes the entire galaxy conforms to an Earth-based calendar system.

  • Zozano@lemy.lol
    link
    fedilink
    English
    arrow-up
    16
    ·
    edit-2
    5 hours ago

    Awww shit, time to rewatch my favourite Jike Mudge movie starring Lon Rivingston; Space Office (9999).

    Haha, I can’t believe this guy has the job of manually changing all the dates on the company’s database, this place sucks. I bet the past was way better.

  • Rusty@lemmy.ca
    link
    fedilink
    English
    arrow-up
    76
    ·
    8 hours ago

    I don’t think 10000 year is a problem. There is a real “year 2038 problem” that affects system storing unix time in signed int32, but it’s mostly solved already. The next problem will be in year 33000 or something like that.

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        9
        ·
        edit-2
        3 hours ago

        A common method of storing dates is the number of seconds since midnight on Jan 1, 1970 (which was somewhat arbitrarily chosen).

        A 32-bit signed integer means it can store numbers between 231 through 231 - 1 (subtracting one comes from zero being effectively a positive number for these purposes). 231 - 1 seconds added to Jan 1, 1970 gets you to Jan 19, 2038.

        The solution is to jump to 64-bit integers, but as with Y2K, there’s a lot of old systems that need to be updated to 64-bit integers (and no, they don’t necessarily have to have 64-bit CPUs to make that work). For the most part, this has been done already. That would put the date out to 292,277,026,596 CE. Which is orders of magnitude past the time for the sun to turn into a red giant.

        • pfm@scribe.disroot.org
          link
          fedilink
          arrow-up
          2
          ·
          1 hour ago

          Maybe it’s not LI5, but I certainly enjoy your explanation for including several important facts and context. I respect your skill and knowledge, dear internet stranger.

        • gandalf_der_12te@discuss.tchncs.de
          link
          fedilink
          arrow-up
          1
          ·
          1 hour ago

          midnight on Jan 1, 1970 (which was somewhat arbitrarily chosen).

          well not so much, as far as I remember the first end-user computers became available in 1971 or 1972 or something, and the internet also underwent some rapid developments in that time, so the date has a certain reasoning to it.

      • teije9@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        7
        ·
        3 hours ago

        Unix computers store time in seconds that have passed since january first 1970. one there have been too many seconds since 1970, it starts breaking. ‘signed’ is a way to store negative numbers in binary. the basics of it are: when the leftmost bit is a 1, it’s a negative number (and then you do some other things to the rest of the number so that it acts like a negative number) so when there have been 09999999 seconds since 1970, if there’s one more second it’ll be 10000000, which a computer sees as -9999999.

    • kevincox@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      4 hours ago

      it’s mostly solved already

      I wished I believe this. Or I guess I agree that it is solved in most software but there is lots of commonly used software where it isn’t. One broken bit of software can fairly easily take down a whole site or OS.

      Try to create an event in 2040 in your favourite calendar. There is a decent chance it isn’t supported. I would say most calendar servers support it, but the frontends often don’t or vice-versa.

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      17
      ·
      6 hours ago

      Well, I looked at a Year 10000 problem less than 2 hours ago. We’re parsing logs to extract the timestamp and for that, we’re using a regex which starts with:

      \d{4}-\d{2}-\d{2}
      

      So, we assume there to be 4 digits for the year, always. Can’t use it, if you live in the year 10000 and beyond, nor in the year 999 and before.

        • Ephera@lemmy.ml
          link
          fedilink
          English
          arrow-up
          3
          ·
          5 hours ago

          Do you think so? Surely, it’s able to handle dates before the year 999 correctly, so I’d also expect it to handle years beyond 10000. The \d{4} is just our bodged assumption, because well, I have actually never seen a log line with a year that wasn’t 4 digits…

          • itslilith@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            5
            ·
            5 hours ago

            Kinda?

            Each date and time value has a fixed number of digits that must be padded with leading zeros.

            To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[21] An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[22] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.[23]

            • Ephera@lemmy.ml
              link
              fedilink
              English
              arrow-up
              2
              ·
              2 hours ago

              Oh wow, I really expected the standard to just say that however many digits you need are fine, because you know, maths. But I guess, this simplifies handling all kinds of edge cases in the roughly 7975 years we’ve still got.

      • marcos@lemmy.world
        link
        fedilink
        arrow-up
        9
        ·
        7 hours ago

        Yes, there are random systems using every kind of smart or brain-dead option out there.

        But the 2038 problem impacts the previous standard, and the current one will take ages to fail. (No, it’s not 33000, unless you are using some variant of the standard that counts nanoseconds instead of seconds. Those usually have more bits nowadays, but some odd older systems do it on the same 64 bits from the standard.)

    • Pennomi@lemmy.world
      link
      fedilink
      English
      arrow-up
      11
      ·
      7 hours ago

      It’s a UX problem rather than a date format problem at that point. Many form fields require exactly 4 digits.

    • GissaMittJobb@lemmy.ml
      link
      fedilink
      arrow-up
      7
      ·
      7 hours ago

      It’s going to be significantly more than the year 33000 before we run out of 64-bit epoch timestamps.

      The max value for signed 64-but epoch values is more than 292 billion years away, or 20 times the age of the universe itself.

      So yeah, we’re basically solid forever with 64-bit

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        3 hours ago

        33,000 would come from other programs that store the year as a 16-bit signed int. Year 32,768, to be precise.

  • Lucy :3@feddit.org
    link
    fedilink
    arrow-up
    92
    ·
    8 hours ago

    Programmers in 292,271,023,045 after uint64_t isn’t enough for the unix timestamp anymore:

  • Gork@lemm.ee
    link
    fedilink
    arrow-up
    45
    ·
    8 hours ago

    There might be a new calendar year system by then. Probably some galactic dictator who says that the beginning of their rule is now Year Zero.

    Year Zero of the Glorious Zorg Empire!

    • Zink@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      3 hours ago

      Ugh, I definitely don’t have the bandwidth to support anything beyond the year graham’s number.

      • niktemadur@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        3 hours ago

        “How many years is that?”
        “At least THIS many.” (holds up 4 Knuth’s arrow notations fingers)