I just fixed my first y2k38 problem on a production system. If you're using unix time_t and you're trying to be smart and have something expire "20 years from now", your code is broken on systems that store time_t as a 32 bit signed integer (Post Jan 19th, 2018. it all breaks.)
time_t should only be used (a) for relative times, e.g. timeouts, and (b) for interfacing with the timekeeping system and conversions to/from broken-down time. Storage and computations with times should be all int64_t.
-
-
It should be "duration_t"
-
I disagree. Use 64-bit time_t and time_t fits all purposes (absolute, relative, and intervals). 32-bit time_t is horribly broken regardless for the reasons laid out by the OP.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.