Johannes Schindelin <johannes.schinde...@gmx.de> writes: > On Tue, 12 Jul 2016, Junio C Hamano wrote: > >> Jeff King <p...@peff.net> 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. > > I kept the unsigned long -> time_t conversion after reading the thread so > far.
That's OK at this point; it is not v2.9.x material anyway. The primary reason why I cared 32-bit time_t is not about 2038, by the way. I recall that people wanted to store historical document with ancient timestamp; even if we update to support negative timestamps, they cannot go back to 19th century with 32-bit time_t, but they can with long long or whatever intmax_t is on their system. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
