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

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

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

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