Re: [ANNOUNCE] Git v2.9.1
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 13, 2016, 14:00 UTC
- Message-ID
- <alpine.DEB.2.20.1607131600110.6426@virtualbox>
- In-Reply-To
- <xmqq60sa7rj2.fsf@gitster.mtv.corp.google.com>
Hi,
On Tue, 12 Jul 2016, Junio C Hamano wrote:
Show 27 quoted lines
> 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 ;-) > > > 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.
Ciao, Dscho