From: Jeff King <peff@peff.net>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: git@vger.kernel.org
Subject: Re: [Bug] git-log prints wrong unixtime with --date=format:%s
Date: Tue, 17 May 2016 20:40:08 -0400 [thread overview]
Message-ID: <20160518004008.GA20007@sigill.intra.peff.net> (raw)
In-Reply-To: <8760ucoaus.fsf@web.de>
On Tue, May 17, 2016 at 07:25:31PM +0200, Michael Heerdegen wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> > the command
> >
> > git log --pretty=format:%ad --date=format:%s
> >
> > displays wrong unixtime values; apparently how much the printed value
> > differs from the expected value depends on the system's time zone and
> > whether daylight savings time is enabled or not.
>
> Two more comments:
>
> - --date=raw seems to work correctly (though the doc tells it would
> also use "%s").
I think the doc is misleading there. None of the date formats except the
recently added "--date=format" use strftime at all.
The problem is almost certainly some mismatch between git's idea of the
timezone and what we are feeding to strftime. I'm not sure if it will be
solvable, though. strftime() takes a "struct tm", which has no timezone
field. We feed it a "struct tm" either in the author's timezone or in
the user's timezone (if "format-local" was used). We could feed it in
UTC, but I'm not sure that solves the problem, and it probably makes new
ones.
In your examples, you showed that setting $TZ changes the epoch time
strftime gives us. Which probably means that it is guessing the fed
"struct tm" is in the local timezone, which would still be wrong.
And even if that did work, feeding it UTC means that all of the other
non-%s values would be in UTC, not in the author's or user's timezone.
So we need some way to tell strftime "...and by the way, this is the
timezone for the value we are currently feeding you." There isn't a slot
in "struct tm" for that, but I think maybe you can hack around it by
setting the global "timezone" variable (and then restoring it
afterwards).
> - When specifying versions like @{N hours}, the result seems to differ
> (by one hour?) from what I expect, too.
This is probably a totally separate issue, as it would not be using
strftime (or IIRC, any of the standard time functions at all). Do you
have a detailed example that shows the problem?
-Peff
next prev parent reply other threads:[~2016-05-18 0:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 23:33 [Bug] git-log prints wrong unixtime with --date=format:%s Michael Heerdegen
2016-05-17 17:25 ` Michael Heerdegen
2016-05-18 0:40 ` Jeff King [this message]
2016-05-18 0:58 ` Jeff King
2016-05-18 16:21 ` Junio C Hamano
2016-05-18 16:44 ` Randall S. Becker
2016-05-18 17:51 ` Jeff King
2016-05-18 17:49 ` Jeff King
2016-05-18 23:05 ` Michael Heerdegen
2016-05-19 1:54 ` Jeff King
2016-05-19 15:41 ` Michael Heerdegen
2016-05-18 22:57 ` Michael Heerdegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160518004008.GA20007@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=michael_heerdegen@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).