Re: [PATCH v3] date: detect underflow/overflow when parsing dates with timezone offset

[Junio C Hamano <gitster@pobox.com>]

Karthik Nayak <karthik.188@gmail.com> writes:

>> It's even OK to use a hard coded constant for the number of days
>> since the epoch to the git-end-of-time ;-)
>
> That's why I noted it as a _Nit_, mostly because it wasn't anything big.
> But I found that part of it being dynamic and part of it being static
> was inconsistent.

Sure, but it is so tiny thing, we shouldn't waste more time than we
spend getting the tests right even on 32-bit systems.  We seem to be
doing the opposite by talking about this part even more, which is a
bit sad.  Any comments on the actual patch I sent as a follow-up?

>> The timestamp of the git-end-of-time would not fit in time_t on
>> 32-bit systems, I would presume?  If our tests are trying to see if
>> timestamps around the beginning of year 2100 are handled
>> "correctly", the definition of the correctness needs to be
>> consitional on the platform.
>>
>> On systems with TIME_T_IS_64BIT, we'd want to see such a timestamp
>> to be represented fine.  On systems without, we'd want to see the
>> "Timestamp too large for this system" error when we feed such a
>> timestamp to be parsed.
>>
>> Thanks.