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

["René Scharfe" <l.s.r@web.de>]

Am 12.06.2017 um 21:02 schrieb Ævar Arnfjörð Bjarmason:
> I only ever use the time offset info to quickly make a mental note of
> "oh +0200, this guy's in Europe", or "oh -0400 America East". Having
> any info at all for %Z would allow me to easily replace that already
> buggy mapping that exists in my head right now with something that's
> at least a bit more accurate, e.g. I remember that +0900 is Japan, but
> I can't now offhand recall what timezones India is at.
> 
> Now, obviously we can't know whether to translate e.g. -0400 to New
> York or Santiago, but for the purposes of human readable output I
> thought it would be more useful to guess than show nothing at all. So
> for that purpose the most useful output of %Z *for me* would be just
> showing a string with the 3 most notable cities/areas, weighted for
> showing locations on different continents, e.g.:
> 
>    +0000 = Iceland, West Africa, Ittoqqortoormiit
>    +0100 = London, Lisbon, Kinshasa
>    ...
>    +0900 = Tokyo, Seul, Manokwari
>    ....
>    -0900 = San Francisco, Vancouver, Tijuana
>    ....
>    -0600 = Denver, Managua, Calgary
> 
> Then I could run:
> 
>      git log --date=format-local:"%Y[...](%Z)"
> 
> And get output like:
> 
>      commit 826c06412e (HEAD -> master, origin/master, origin/HEAD)
>      Author: Junio C Hamano <gitster@pobox.com>
>      Date:   Fri Jun 2 15:07:36 2017 +0900 (San Francisco, Vancouver,
> Tijuana etc.)
> 
>      Fifth batch for 2.14
>      [...]
>      commit 30d005c020
>      Author: Jeff King <peff@peff.net>
>      Date:   Fri May 19 08:59:34 2017 -0400 (New York, Havana, Santiago etc.)
> 
>          diff: use blob path for blob/file diffs
> 
> Which gives me a pretty good idea of where the people who are making
> my colleges / collaborators who are making commits all over the world
> are located, for the purposes of reinforcing the abstract numeric
> mapping with a best-guess at what the location might be, or at least
> something that's close to the actual location.

Half the time this would be off by a zone in areas that use daylight
saving time, or you'd need to determine when DST starts and ends, but
since that depends on the exact time zone it will be tricky.

You could use military time zones, which are nice and easy to convert:
Alpha (UTC+1) to Mike (UTC+12) (Juliet is skipped), November (UTC-1) to 
Yankee (UTC-12), and Zulu time zone (UTC+0).  Downside: Most civilians
don't use them. :)  Also there are no names for zones that have an
offset of a fraction of an hour.

> I'd definitely use a feature like that, and could hack it up on top of
> the current patches if there wasn't vehement opposition to it. Maybe
> the above examples change someone's mind, I can't think of a case
> where someone's relying on %Z now for date-local, or at least cases
> where something like the above wouldn't be more useful in practice
> than just an empty string, but if nobody agrees so be it :)

Personally I don't have a use for time information; dates alone would
suffice for me -- so I certainly won't hold you back.  But I don't see
how it could be done.

René