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.").

Reply via email to