Thank you for the clarification, it's really a disappointing answer. Perhaps the manual needs to be clearer about this limitation. On Sun, Oct 31, 2021 at 4:53 PM Jeff King <peff@xxxxxxxx> wrote: > > 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/
