Re: [PATCH 0/6] Use time_t

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2017, 22:48 UTC
Message-ID: <xmqqlgsrmesc.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <cover.1488231002.git.johannes.schindelin@gmx.de>

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

Show 8 quoted lines

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

s/ulong/time_t/ is definintely a good change, and it will take us to a place we would want to be in in some future.

As long as there remains no platform we care about whose time_t and long are still 32-bit signed integer, there will be a fallout to them with this change. Probably it is of a larger impact than losing the upper half of a 64-bit timestamp range on larger boxes. Hopefully those platforms have died out (or at least we don't mind breaking them)?

It appears that we use uint64_t in many places in our code. So while philosophically time_t is the right type, uint64_t might be practically a safer alternative type to use at the endgame patch in this series. I haven't seen it yet, but presumably the last one 6/6 is the endgame?