The question asked is valid, and we do commit often, we only avoid pushes to shared spaces at night, so some commits may have representative time stamps. As others have mentioned, squashing might compromise that, and commits made Friday but pushed Monday are, in my experience, more likely to be modified Monday right before pushing. For me, it’s pretty rare that the first commit time survives until push, I’m almost always squashing code, multiple times, before it’s ever pushed.
Unfortunately, TFA doesn't discuss which timestamp is being looked at, though that leads me to suspect that it's looking at the author timestamp because that's the default.
You're only talking about the first commit in a squash, and assuming that there aren't multiple squashes, right? There isn't only one timestamp in a squash, so you lose all but one of them.
> I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream.
Right, exactly, this illustrates why looking at timestamps isn't a good proxy for work time.
> TFA doesn't discuss which timestamp is being looked at
Here's the relevant portion of the script from the article:
git log --author="Linus Torvalds" --date=iso