Re: [PATCH 0/6] Use time_t

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 1, 2017, 17:23 UTC
Message-ID: <xmqq1sugj4gn.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170228223325.vabdrwas2qn52gup@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 21 quoted lines

> On Tue, Feb 28, 2017 at 02:27:22PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > ... We can certainly stick with it for now (it's awkward if you
>> > really do have an entry on Jan 1 1970, but other than that it's an OK
>> > marker). I agree that the most negatively value is probably a saner
>> > choice, but we can switch to it after the dust settles.
>> 
>> I was trying to suggest that we should strive to switch to the most
>> negative or whatever the most implausible value in the new range
>> (and leave it as a possible bug to be fixed if we missed a place
>> that still used "0 is impossible") while doing the ulong to time_t
>> (or timestamp_t that is i64).  
>> 
>> "safer in the short term" wasn't meant to be "let's not spend time
>> to do quality work".  As long as we are switching, we should follow
>> it through.
>
> Sure, I'd be much happier to see it done now. I just didn't want to pile
> on the requirements to the point that step 1 doesn't get done.

Ah, that was what you meant.

I was assuming that we are switching to a longer _signed_ type. It felt silly to tell users "you can use timestamps before the epoch now with this change, but you cannot express time exactly at the epoch".

I am perfectly OK with switching to a longer _unsigned_ type with the "0 is impossible" [*1*] intact, aka "safer in the short term", if we want to it make our first step. That may be a smaller step, but still a step in the right direction.

[Footnote]

*1* It could be "-1 is impossible", I didn't actually check.
    Funnily enough, ISO C99 uses (time_t)(-1) to signal an error
    when returning value from mktime() and time().