Re: git-2.13.0: log --date=format:%z not working

From: René Scharfe <l.s.r@web.de>
Date: Jun 2, 2017, 17:25 UTC
Message-ID: <72b001fc-80e7-42b9-bd9d-87621da7978a@web.de>
In-Reply-To: <20170602030825.hdpbaisn54d4fi4n@sigill.intra.peff.net>

Am 02.06.2017 um 05:08 schrieb Jeff King:

Show 18 quoted lines

> In theory the solution is:
> 
>    1. Start using localtime() instead of gmtime() with an adjustment when
>       we are converting to the local timezone (i.e., format-local). We
>       should be able to do this portably.
> 
>       This is easy to do, and it's better than handling %z ourselves,
>       because it makes %Z work, too.
> 
>    2. When showing the author's timezone, do some trickery to set the
>       program's timezone, then use localtime(), then restore the program
>       timezone.
> 
>       I couldn't get this to work reliably. And anyway, we'd still have
>       nothing to put in %Z since we don't have a timezone name at all in
>       the git objects. We just have "+0400" or whatever.
> 
> So I don't see a portable way to make (2) work.

We could create a strftime wrapper that also takes a time zone offset, with platform-specific implementations. Is it worth the effort?

What reliability issues did you run into?

Show 12 quoted lines

> But it seems a shame
> that %Z does not work for case (1) with René's patch.
> 
> I guess we could do (1) for the local cases and then handle "%z"
> ourselves otherwise. That sounds even _more_ confusing, but it at least
> gets the most cases right.
> 
> If we do handle "%z" ourselves (either always or for just the one case),
> what should the matching %Z say? Right now (and I think with René's
> patch) it says GMT, which is actively misleading. We should probably
> replace it with the same text as "%z". That's not quite what the user
> wanted, but at least it's accurate.

On Linux "%z %Z" is expanded to "+0200 CEST" for me, while on Windows I get "Mitteleurop▒ische Sommerzeit Mitteleurop▒ische Sommerzeit". (That "▒" is probably supposed to be an "ä".) POSIX requires +hhmm or -hhmm format for %z, and for %Z is to be "Replaced by the timezone name or abbreviation".

I'd say "GMT+0200" etc. is a nice enough timezone name, i.e. having %Z resolve to the same as %z plus a literal prefix of "GMT" should at least not be wrong.

Alternatively we could have a lookup table mapping a few typical offsets to timezone names, but e.g. handling daylight saving times would probably be too hard (when did that part of the world switch in the given year? north or south of the equator?)..

> As far as the patch itself goes, I'm disappointed to lose the automatic
> "%" handling for all of the other callers. But I suspect the boilerplate
> involved in any solution that lets callers choose whether or not to use
> it would end up being longer than just handling it in each caller.

Actually I felt uneasy when you added that forced %% handling because it put a policy into an otherwise neutral interpreter function. I just had no practical argument against it -- until now.

I'd rather see strbuf_expand also lose the hard-coded percent sign, but again I don't have an actual user for such a flexibility (yet).

Perhaps we should add a fully neutral strbuf_expand_core (or whatever), make strbuf_expand a wrapper with hard-coded % and %% handling and use the core function in the strftime wrapper. Except that the function is not easily stackable. Hmm..

René