time_t 1500000000

Sorry for the late notice, but a few minutes ago, time_t hit 1,500,000,000. That's a bit over ⅓ of the way until we run out of time. And just think, you were there.

Previously, previously, previously, previously.

Tags: , ,

25 Responses:

  1. Line Noise says:

    It happened at lunchtime here in Australia. A small cheer when up around the office at 12:40pm. What an amazing time to be alive!

  2. You're going to need a bigger int.

  3. eSyr says:

    On an unrelated note, not quite lament configuration, but still: https://i.imgur.com/BURyFZX.mp4

  4. kbrint says:

    time_t is signed, so we're over ⅔ already. There is only 31% of time left.

    • BHN says:

      'now has passed.'

    • MetaRZA says:

      Since y2k, I've always thought the "solution" to the time_t problem is make it unsigned int. OK, not a perfect solution but it would gain us a few decades to upgrade to 256 bit architectures.

  5. robert_ says:

    carpe time_t

  6. Wotsac says:

    I'm hoping that my familiarity with a bunch of old *nix will let me substantially pad my retirement funds between 2034 and 2038, as with the COBOL greybeards of the late '90s. My beard should be most excellent and most grey by then.

  7. robert_ says:

    Every event needs a cake:

  8. Otto says:

    I thought time_t hit the halfway mark in 2004? Or is 2038 a horrible lie?

    • jwz says:

      Depends on whether you think it's a signed value:

      % perl -e 'print localtime(0x3FFFFFFF)."\n"'
      Sat Jan 10 05:37:03 2004
      % perl -e 'print localtime(0x7FFFFFFF)."\n"'
      Mon Jan 18 19:14:07 2038
      % perl -e 'print localtime(0xFFFFFFFF)."\n"'
      Sat Feb  6 22:28:15 2106

      • Philip Guenther says:

        I think it's the base-2 vs base-10 thing making it confusing in this case:

        $ perl -le 'print "$_\t".localtime($_) for 10**9, 2**30, 1.5*10**9,2**31'
        1000000000 Sat Sep 8 18:46:40 2001
        1073741824 Sat Jan 10 05:37:04 2004
        1500000000 Thu Jul 13 19:40:00 2017
        2147483648 Mon Jan 18 19:14:08 2038

        As for making time_t unsigned, I suggest that you'll despair of the amount of code that assumes it can subtract time_t values and then compare them against small values on the assumption that they can go negative. I say this as the guy who changed the type of time_t on OpenBSD to always be a signed 64bit type** and looked at piles of time handling code as a result. Some protocols and file formats can treat values as unsigned, but the time_t type better be signed, as upstreaming patches to support an unsigned time_t would be an exercise in masochism.

        ** testing this by watching a laptop tick over 2^31 felt weird; what will I be doing when 2038 actually comes? Madly fixing systems? Enjoying retirement? Or hiding from the collapse of civilization on a Pacific island?

        • jwz says:

          testing this by watching a laptop tick over 2^31 felt weird

          Yeah, that is some Deepness In The Sky shit. That's never going to happen, but maybe someone's N-deep legacy system is going to simulate what you might have done.

  9. deater says:

    Does anyone actually pay attention to the decimal time_t on a day-to-day basis?

    I actually have two different clocks on my desk that show time_t, but in binary, so a base-10 rollover isn't really that interesting to look at.

    (And no, the clocks are not y2038 compliant, though one of them can be extended to 40 bits with a quick software update if necessary)

  10. internetimal says:

    This seems like a good time to mention that you might enjoy "Reset."

  11. Winston says:

    Re the signed/unsigned issue, the standard library function "time", which returns a time_t value, is supposed to return -1 if the time is not available. How would it do that if time_t is unsigned?

    • MetaRZA says:

      "time is not available" Is there a currently running system where this is possible?

      • Moofie says:

        Error handling code often goes something like if (myTime <= 0) { ... error handling } else { ... do something } . Making time_t have legitimate negative values would mess up lots of code. Worse yet older code usually doesn't have unit tests so finding all the places where negative numbers are errors is a nightmare. This is why Philip Guenther extended time_t to a signed 64bit integer instead of trying to make is signed. He wrote procmail so if it's too complicated for him then you probably don't want to go there.

      • Philip Guenther says:

        Historically, time() could fail with EFAULT if passed an invalid pointer, but yeah, modern implementation will just segv if you do that and time() will never fail until time_t wraps. (If you see code that tests for EFAULT it should be updated using "rm")

        On the other hand, mktime() can fail and return (time_t)-1 if there's an overflow during the normalization, but the standard describes the return value as -1 converted to time_t type, so if time_t was unsigned it would just turn into a huge value. Code that does "if (mktime(...) == -1) { handle_error(...); }" does work if time_t is unsigned int (or larger), but there are enough other idioms that'll fail that it would still be a Bad Idea.

    • jwz says:

      Never in my life have I seen code that checked to see if time() returned an error.

  12. Lloyd says:

    if (myTime <= 0)....

    Is that <= time's arrow? because I googled time's arrow, and now I'm confused.

  • Previously