On Sun, Oct 31, 2021 at 11:23:24AM +0800, Dongsheng Song wrote:
> I found a timezone related bug in the git:
>
> 1. git log 11990eba -1 --date=format:%s
>
> commit 11990eba0be50d1ad0655ede4062b7130326c41f (HEAD -> trunk,
> origin/trunk, origin/HEAD)
> Author: rillig <rillig@xxxxxxxxxx>
> Date: 1635604878
>
> indent: move debugging functions to a separate section
>
> 2. git cat-file -p 11990eba
>
> tree 5d62150f5e2bafd3db76641450ca5d902302a039
> parent 892557a74bd49983fac28366b772b53c9216ca73
> author rillig <rillig@xxxxxxxxxx> 1635633678 +0000
> committer rillig <rillig@xxxxxxxxxx> 1635633678 +0000
>
> indent: move debugging functions to a separate section
>
> 3. conclusion
>
> The unix time stored in git repository not same as the git log output,
> then there must be a timezone offset bug:
>
> 1635633678 - 1635604878 = 28800 = 8 hours (local timezone offset)
The short answer is: don't do that. Use --date=unix instead.
The longer one is:
The problem is that the strftime() "%s" specifier is a bit broken.
That function (which is what is interpreting your format) takes a
broken-down "struct tm", which can only be converted back to an epoch
time if you know which time zone it's in.
But we have no way to tell the function that; the standard indicates
that it always assumes the local system timezone, and there's no
provision at all for formatting times in other zones (which is what we
usually try to do, showing the date in the author's zone). There's no
field in the "struct tm" to carry any zone information[1].
Even when you're in the same timezone, there's a similar problem with
the is_dst field. There's some discussion in [2], including the
possibility of intercepting "%s" and handling it ourselves, like we do
for "%z". I don't think anybody has cared enough to work on it.
-Peff
[1] Some implementations (like glibc) actually _do_ carry this
information in private fields of "struct tm". But we can't rely on
it, and even where it's available, it's confusing (e.g., mktime()
ignores it!). If you're a real masochist, you can read all of:
https://lore.kernel.org/git/22824.29946.305300.380299@xxxxxxxxxxxxxxxxxxxxxx/
[2] This is a similar bug report from 2020:
https://lore.kernel.org/git/CAGqZTUu2U6FFXGTXihC64O0gB5Bz_Z3MbD750kMoJWMciAGH6w@xxxxxxxxxxxxxx/
