On Mon, Jun 12, 2017 at 5:12 PM, Junio C Hamano <gits...@pobox.com> wrote: > René Scharfe <l....@web.de> 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)?
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. 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.").
