Okay, upon investigation this might be a non-bug. GitHub hides the fact that each commit actually has two timestamps, and only shows the author timestamp, but Gitiles reports the author timestamp and the commit timestamp correctly.

It's still odd that the behavior appears to be different for Chromium and Catapult. In Chromium, Gitiles seems to show that the author and commit timestamps are synchronized, whereas in Catapult, Gitiles shows that the author timestamp is the date the CL was created.

Gerrit has a per-repository setting called "matchAuthorToCommitterDate" (https://gerrit-review.googlesource.com/Documentation/config-project-config.html#submit-section). If that setting is True, and the repo already uses a submit strategy which synthesizes a new commit at submit time (e.g. Rebase Always), then the Author and Committer dates will be made to match.

This setting was created specifically for Chromium, because chromium engineers were accustomed to the commit objects being generated by the CQ (after it downloaded and applied the diff from Rietveld), and therefore having matching author and committer timestamps anyway. Turning this setting on *is* explicitly a loss of information, and isn't the way most other git projects behave. But there's a legitimate argument that, especially in chromium-style projects, the information it loses is unimportant, and the benefit of having matching dates and having the same settings as chromium itself is reasonable.

If catapult wants this, we can set it there.

Thanks for the very detailed explanation! To be honest, I don't particularly care about synchronizing the timestamps but also don't feel that the author timestamp is very useful. But since doing nothing would be less work, I think that's fine with me.

I noticed that Gitiles does the "right thing", i.e. shows the commit timestamp rather than the author timestamp that GitHub shows, and I expect personally to be linking more frequently to Gitiles and less frequently to GitHub, going forward.