Re: [ANNOUNCE] Git v2.9.1

Jeff King [off-list ref] 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.

Hi,

On Tue, 12 Jul 2016, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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

quoted

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 ;-)

quoted

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