Re: [PATCH v2] date: detect underflow when parsing dates with positive timezone offset

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jun 5, 2024, 13:10 UTC
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:

Show 20 quoted lines

> 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

Show 8 quoted lines

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