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.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.
Tags: computers, firstperson, time_t
25 Responses:
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!
You're going to need a bigger int.
On an unrelated note, not quite lament configuration, but still: https://i.imgur.com/BURyFZX.mp4
Neat, a 10MB gif.
The original youtube video might be a better link: https://www.youtube.com/watch?v=xzACu6Bey1w
Favorite comment: "You want cenobites? Because that's how you get cenobites."
time_tis signed, so we're over ⅔ already. There is only 31% of time left.'now has passed.'
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.
carpe time_t
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.
Every event needs a cake:
I thought time_t hit the halfway mark in 2004? Or is 2038 a horrible lie?
Depends on whether you think it's a signed value:
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?
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.
That was such a good book.
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)
This seems like a good time to mention that you might enjoy "Reset."
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?
"time is not available" Is there a currently running system where this is possible?
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.^H^H^H^H make it unsigned
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.
Never in my life have I seen code that checked to see if time() returned an error.
if (myTime <= 0)....
Is that <= time's arrow? because I googled time's arrow, and now I'm confused.