Thread (70 messages) 70 messages, 6 authors, 2017-04-26

Re: [PATCH 0/6] Use time_t

From: Johannes Schindelin <hidden>
Date: 2017-02-28 15:10:41

Hi Peff,

On Tue, 28 Feb 2017, Jeff King wrote:
On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote:
quoted
One notable fallout of this patch series is that on 64-bit Linux (and
other platforms where `unsigned long` is 64-bit), we now limit the
range of dates to LONG_MAX (i.e. the *signed* maximum value). This
needs to be done as `time_t` can be signed (and indeed is at least on
my Ubuntu setup).

Obviously, I think that we can live with that, and I hope that all
interested parties agree.
I do not just agree, but I think the move to a signed timestamp is a big
improvement. Git's object format is happy to represent times before
1970, but the code is not. I know this has been a pain for people who
import ancient histories into Git.

It looks from the discussion like the sanest path forward is our own
signed-64bit timestamp_t. That's unfortunate compared to using the
standard time_t, but hopefully it would reduce the number of knobs (like
TIME_T_IS_INT64) in the long run.
Boy am I happy that I did not go ahead and changed the code to use
uint64_t yet...

I'll let the dust settle a bit and then make further changes and send out
v2.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help