>>>>> On Mon, 12 Jun 2017, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jun 12, 2017 at 5:12 PM, Junio C Hamano <gits...@pobox.com> wrote: >> René Scharfe <l....@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
