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

From: Karthik Nayak <karthik.188@gmail.com>
Date: Jun 14, 2024, 20:09 UTC
Message-ID: <CAOLa=ZT2goTBD6WBtjYOYqa6vEsp=P=UzUBzs-5Om3d9HLZYbw@mail.gmail.com>
In-Reply-To: <xmqqle38n7hv.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 17 quoted lines

> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>>>> +/* timestamp of 2099-12-31T23:59:59Z, including 32 leap days */
>>>> +static const time_t timestamp_max = ((2100L - 1970) * 365 + 32) * 24 * 60 * 60 - 1;
>>>>
>>> Nit: but since we're calculating the number of years here (2100L -
>>> 1970), shouldn't we also be calculating the number of leap days instead
>>> of hardcoding it?
>>
>> I'm happy with a hard coded constant for the number of leap days - I
>> think it is probably easier to check that (which I have done) than it
>> would be to check the calculation as I'm not sure off the top of my
>> head if is it safe to do (2100-1970)/4 or whether we need something
>> more complicated.
>
> 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.

Show 12 quoted lines

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