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.