Jeff King <[email protected]> writes:
> On Tue, Feb 28, 2017 at 02:27:22PM -0800, Junio C Hamano wrote:
>
>> Jeff King <[email protected]> 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().
