From: Phillip Wood <phillip.wood123@gmail.com>
Date: Wed, 05 Jun 2024 13:10:23 GMT
Subject: Re: [PATCH v2] date: detect underflow when parsing dates with positive timezone offset
Message-ID: <7ae05b6a-fb63-4ec7-8006-e968862cc5c7@gmail.com>
In-Reply-To: <4574e410-ca1a-495f-9835-14ee3fa454a1@gmail.com>

On 04/06/2024 09:48, darcy wrote:
> 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;

Thanks for taking a closer look, I wasn't aware of that. Reading Peff's 
reply it seems like timestamp is actually unsigned and as we limit the 
maximum year to 2099 it seems unlikely we'll overflow from too larger 
date after all.

Best Wishes

Phillip

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