From: darcy <acednes@gmail.com>
Date: Tue, 04 Jun 2024 08:48:59 GMT
Subject: Re: [PATCH v2] date: detect underflow when parsing dates with positive timezone offset
Message-ID: <4574e410-ca1a-495f-9835-14ee3fa454a1@gmail.com>
In-Reply-To: <67c23773-21a4-4ad5-9b98-5e44578166dd@gmail.com>

On 4/6/24 00:13, Phillip Wood wrote:

> Hi darcy
> On 03/06/2024 12:44, darcy wrote:
>>> Do we also want to check for overflows in the other direction (a large
>>> timestamp with a negative timezone offset)?
>> Is this something people want added? I am happy to implement this if
>> so, though it wasn't my original intention.
> I think if we're worried about the date overflowing in one direction it
> makes sense to fix overflows in the other direction at the same time
> especially as I think that the other case involves a signed integer
> overflow which is undefined behavior in C.

That makes sense.

Though I am reading the `tm_to_time_t` code now and it only allows years
up to 2099.

> 	if (year < 0 || year > 129) /* algo only works for 1970-2099 */
>		return -1;

I can of course add a check here for dates close to the end of 2099, but
it seems that the bigger issue is that some day people will want to use
Git after 2099... Should I see if I can extend this range? I'm not sure
where that specific year comes from, it doesn't seem to be based on a
limit of the size of `time_t`, and the comment or git logs don't seem to
provide a reason.