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

[Ulrich Mueller <ulm@gentoo.org>]

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

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

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

IMHO the two viable possibilities are the empty string, or the same
information as for %z. But this has been said before in this thread.

tzdata2017b has the following data in its "etcetera" file, the last
column being the timezone name:

   Zone	    Etc/GMT 	     0	-    GMT

   Zone	    Etc/GMT-14	    14	-    +14
   Zone	    Etc/GMT-13	    13	-    +13
   [...]
   Zone	    Etc/GMT+12	   -12	-    -12

This would be at least some rationale for converting %Z to [+-]hhmm,
i.e., the same as for %z. (One could even think about [+-]hh if the
minutes part is zero, but this already looks like over-engineering
to me.)

Ulrich