Re: [ANNOUNCE] Git v2.9.1

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 12, 2016, 16:25 UTC
Message-ID: <xmqq60sa7rj2.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160712160921.GA2965@sigill.intra.peff.net>

Jeff King <peff@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 ;-)

Show 5 quoted lines

> 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.