Re: [PATCH] strbuf: let strbuf_addftime handle %z and %Z itself

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Jun 12, 2017 at 6:56 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Mon, 12 Jun 2017, Ęvar Arnfjörš Bjarmason wrote:
>
>> On Mon, Jun 12, 2017 at 5:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> René Scharfe <l.s.r@web.de> writes:
>>>> 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
>
> That cannot work, because there is no unique mapping from offset to
> timezone name. For a given offset there may be several timezone names,
> or no name at all. (For example, if I decide to commit with my local
> mean time which has an offset of +0033 then there won't be any
> timezone name at all.)

Yes, I understand that it's a 1:many not a 1:1 mapping. What I'm
saying is that %Z in the context of git-log means a human readable
timezone name, and we can just make a best-effort at guessing that by
picking 1/many out of the 1:many mapping.

This obviously doesn't give us the user's timezone, but when you're
browsing through git log you can get an approximate human-readable
idea of what timezone someone was located in, and that's the whole
point of %Z in the context of how it would be used via git-log, isn't
it?

>> 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.
>
> Please don't. Outputting invented information for something that
> really isn't in the data is worse than outputting no information at
> all.

It's not invented information. %z being +0900 is the same thing as %Z
being JST since +0900 == JST, just because some other things are also
== +0900 that doesn't mean that JST is invalid or less useful than
+0900 or "" for the purposes of human-readable output.