Am 12.06.2017 um 18:16 schrieb Ævar Arnfjörð Bjarmason:
On Mon, Jun 12, 2017 at 5:12 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
René Scharfe <l.s.r@xxxxxx> writes:
Am 07.06.2017 um 10:17 schrieb Jeff King:
On Sat, Jun 03, 2017 at 12:40:34PM +0200, René Scharfe wrote:
Duplicates strbuf_expand to a certain extent, but not too badly, I
think. Leaves the door open for letting strftime handle the local
case.
I guess you'd plan to do that like this in the caller:
if (date->local)
tz_name = NULL;
else
tz_name = "";
and then your strftime() doesn't do any %z expansion when tz_name is
NULL.
Yes, or you could look up a time zone name somewhere else -- except we
don't have a way to do that, at least for now.
Is that only "for now"? I have a feeling that it is fundamentally
impossible with the data we record. When GMTOFF 9:00 is the only
thing we have for a timestamp, can we tell if we should label it as
JST (aka Asia/Tokyo) or KST (aka Asia/Seoul)?
We could track the time zone on commit, e.g. in a new header. I doubt
that the need for showing time zone names will be strong enough to go to
that length, though.
It's obviously not perfect for all the reasons mentioned in this
thread, but we already have a timezone->offset mapping in the
timezone_names variable in date.c, a good enough solution might be to
simply reverse that lookup when formatting %Z
Of course we can never know if you were in Tokyo or Seul from the info
in the commit object, but we don't need to, it's enough that we just
emit JST for +0900 and anyone reading the output has at least some
idea what +0900 maps to.
I suspect that there will be different opinions, for cultural and
political reasons.
We could also simply replace "%Z" with the empty string, as the the
POSIX strftime() documentation allows for:
http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html
("Replaced by the timezone name or abbreviation, or by no bytes if no
timezone information exists.").
Yes, that's what the patch does.
René