threads / discuss / 52443

Gmail munges dates?

Subject: Gmail munges dates?

## tl;dr

4 messages between Dec 13, 2019 and Dec 13, 2019.

replies: 3people: 3as markdown or json

Denton Liu· Dec 13, 2019, 01:57 UTC · lore
Hi all,

It seems like Gmail is munging the dates on patches sent. Before today, I've been sending patches out with mutt but I decided to switch to git-send-email today since I was forwarding a patch that wasn't mine and I wanted to preserve the date as part of the authorship information.

Unfortunately, it seems like mutt wasn't the culprit, it was Gmail that's been munging the dates. For example, in this patch[1], the date shows as

	Date: Thu, 12 Dec 2019 16:44:50 -0800
even though locally, the output of the format-patch shows as
	Date: Mon, 9 Dec 2019 19:25:34 +0100
So two questions related to this:
1. Is this something that we care about or is it okay to have fudged
dates? (I know all of my patches in each patchset only differ by a few
seconds and it seems like no one has noticed or cared so far)
2. Do we want to introduce a --in-body-date option or something to
format-patch which would include an in-body Date:, similar to the
in-body From:? (Also, while we're at it, maybe we could include an
--in-body-from to force that to happen since that's been a feature that
was requested in the past[2])
Thanks,
Denton

[1]: https://lore.kernel.org/git/8691ed2b84f7ee6b7c12d04d57a541bf22660333.1576197846.git.liu.denton@gmail.com/ [2]: https://lore.kernel.org/git/20191010225405.GA19475@sigill.intra.peff.net/

Jeff King· Dec 13, 2019, 05:42 UTC · re: Denton Liu · lore

Re: Gmail munges dates?

On Thu, Dec 12, 2019 at 05:57:53PM -0800, Denton Liu wrote:
Show 14 quoted lines
> It seems like Gmail is munging the dates on patches sent. Before today,
> I've been sending patches out with mutt but I decided to switch to
> git-send-email today since I was forwarding a patch that wasn't mine and
> I wanted to preserve the date as part of the authorship information.
> 
> Unfortunately, it seems like mutt wasn't the culprit, it was Gmail
> that's been munging the dates. For example, in this patch[1], the date
> shows as
> 
> 	Date: Thu, 12 Dec 2019 16:44:50 -0800
> 
> even though locally, the output of the format-patch shows as
> 
> 	Date: Mon, 9 Dec 2019 19:25:34 +0100

Both mutt and git-send-email will munge the headers. And they really need to, since sending a message whose Date header is several days old (or much more, in some cases) is likely to trigger spam filters.

Show 5 quoted lines
> So two questions related to this:
> 
> 1. Is this something that we care about or is it okay to have fudged
> dates? (I know all of my patches in each patchset only differ by a few
> seconds and it seems like no one has noticed or cared so far)

It's OK to have fudged dates. In fact, I think you could make an argument that it's preferable for our development flow. It treats the patch hitting the list as the moment of authorship. When reading "git log" later, that would put its author date near its peers. Of course in a non-linear history you probably care more about "when did this hit master", but the author timestamps are a rough approximation for "era". And of course the committer information could tell you more there, but we don't tend to show it by default.

So I think there are philosophical arguments to be made, but for practical purposes, I think everybody is reasonably happy with the current mechanisms.

There are cases when you might want to preserve old date information (say, re-sending a patch that was several years old). Usually in that case I'd leave the author date as current but make a note about the patch's history if it's relevant.

Show 5 quoted lines
> 2. Do we want to introduce a --in-body-date option or something to
> format-patch which would include an in-body Date:, similar to the
> in-body From:? (Also, while we're at it, maybe we could include an
> --in-body-from to force that to happen since that's been a feature that
> was requested in the past[2])

I doubt I'd use it myself, but I wouldn't be opposed to an in-body-date option. You'd perhaps want to define some heuristics to avoid uninteresting noise. If your patch is from 10 minutes ago, and you are just now sending it in, adding the extra date header is mostly just clutter. So perhaps you'd want it to kick in when the date is more than N time units or something.

-Peff
Junio C Hamano· Dec 13, 2019, 17:52 UTC · re: Jeff King · lore

Re: Gmail munges dates?

Jeff King <peff@peff.net> writes:
Show 12 quoted lines
>> 2. Do we want to introduce a --in-body-date option or something to
>> format-patch which would include an in-body Date:, similar to the
>> in-body From:? (Also, while we're at it, maybe we could include an
>> --in-body-from to force that to happen since that's been a feature that
>> was requested in the past[2])
>
> I doubt I'd use it myself, but I wouldn't be opposed to an in-body-date
> option. You'd perhaps want to define some heuristics to avoid
> uninteresting noise. If your patch is from 10 minutes ago, and you are
> just now sending it in, adding the extra date header is mostly just
> clutter. So perhaps you'd want it to kick in when the date is more than
> N time units or something.

I do not have a fundamental objection to the --in-body-date option, either, although I do not want to see it used when sending patches to this list.

As long as it is a command-line per-invocation option, I do not think you'd need any "uninteresting noise filtering" logic. A configuration variable to always do so would cause a huge headache to keep the behaviour sensible when sending one's own patches, and would require such filtering, I would think.

Thanks.
Junio C Hamano· Dec 13, 2019, 17:47 UTC · re: Denton Liu · lore

Re: Gmail munges dates?

Denton Liu <liu.denton@gmail.com> writes:
Show 9 quoted lines
> Unfortunately, it seems like mutt wasn't the culprit, it was Gmail
> that's been munging the dates. For example, in this patch[1], the date
> shows as
>
> 	Date: Thu, 12 Dec 2019 16:44:50 -0800
>
> even though locally, the output of the format-patch shows as
>
> 	Date: Mon, 9 Dec 2019 19:25:34 +0100

"git send-email" records the timestamp of sending. If you really want to force a specific author date, you could add a in-body Date: but it is discouraged in mailing-list centric workflow, because it is more natural for everybody other than the author to consider that the time the patch hits the list, i.e. the public eyes, is when the patch was "authored".

← back to recent threads