Re: [Bug] git-log prints wrong unixtime with --date=format:%s

From: Jeff King <peff@peff.net>
Date: May 18, 2016, 00:40 UTC
Message-ID: <20160518004008.GA20007@sigill.intra.peff.net>
In-Reply-To: <8760ucoaus.fsf@web.de>

On Tue, May 17, 2016 at 07:25:31PM +0200, Michael Heerdegen wrote:

Show 14 quoted lines

> 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