Re: [PATCH] fix: prevent date underflow when using positive timezone offset

From: Junio C Hamano <gitster@pobox.com>
Date: May 28, 2024, 17:06 UTC
Message-ID: <xmqqmso96f3j.fsf@gitster.g>
In-Reply-To: <ZlXkvEeR-PgZMitx@tanuki>

Patrick Steinhardt <ps@pks.im> writes:

Show 13 quoted lines

> On Mon, May 27, 2024 at 09:17:06AM +0000, darcy via GitGitGadget wrote:
>> From: darcy <acednes@gmail.com>
>
> The commit message should start with the subsystem that you're touching,
> which in this case would be "date", e.g.:
>
>     date: detect underflow when parsing dates with positive timezone offset
>
>> Overriding the date of a commit to be `1970-01-01` with a large enough
>> timezone for the equivalent GMT time to before 1970 is no longer
>> accepted.
>
> Okay.

"is no longer accepted" made me read the sentence three times to get what the author wants to say. Initially I thought the author wanted to report a regression where we used to accept but with a recent change we stopped accepting.

In our convention, we present the status quo, point out why it is awkard/incorrect/bad, and then propose a new behaviour.

    Overriding ... before 1970 BEHAVES THIS WAY.

    This leads to BAD BEHAVIOUR FOR SUCH AND SUCH REASONS.

    Instead check the timezone offset and fail if the resulting time
    becomes before the epoch, "1970-01-01T00:00:00Z", when parsing.

with the blanks filled in appropriately would have been much easier to see.

Show 6 quoted lines

>> Example: `GIT_COMMITTER_DATE='1970-01-01T00:00:00+10' git commit` would
>> previously be accepted, only to unexpectedly fail in other parts of the
>> code, such as `git push`. The timestamp is now checked against postitive
>> timezone values.
>
> How exactly does the failure look like before and after?

Yes, good question.

>> Signed-off-by: darcy <acednes@gmail.com>
>> ---

I cannot offhand tell if Documentation/SubmittingPatches:real-name is followed here or ignored, so just to double check...

Everything else in your review made sense to me. I guess that checking for tm_hour is assuming that TZ offset should always come before the values necessary to compute the timestamp comes, but it smells like an unwarranted assumption and not explaining the change in the proposed log message is a bad sign.

Thanks.