Am 02.06.2017 um 05:08 schrieb Jeff King:
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?
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é