Jeff King <peff@xxxxxxxx> writes: > In case it wasn't clear, I was mostly guessing there. So I dug a bit > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t > on i386 because of the ABI headaches. X-< (yes, I knew). > That being said, I still think the "clamp to time_t" strategy is > reasonable. Unless you are doing something really exotic like pretending > to be from the future, nobody will care for 20 years. Yup. It is a minor regression for them to go from ulong to time_t, because they didn't have to care for 90 years or so but now they do in 20 years, I'd guess, but hopefully after that many years, everybody's time_t would be sufficiently large. I suspect Cobol programmers in the 50s would have said a similar thing about the y2k timebomb they created back then, though ;-) > And at that point, systems with a 32-bit time_t are going to have > to do _something_, because time() is going to start returning > bogus values. So as long as we behave reasonably (e.g., clamping > values and not generating wrapped nonsense), I think that's a fine > solution. OK. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html