Re: [PATCH] strbuf: let strbuf_addftime handle %z and %Z itself
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jun 13, 2017, 10:16 UTC
- Message-ID
- <CACBZZX4w1OKYZ2uiBSB7S1hO7tUzqvfWskmCJmMmtBebNRDPCQ@mail.gmail.com>
- In-Reply-To
- <c7532160-53eb-a0c5-94e6-483aadf0cfc5@web.de>
On Tue, Jun 13, 2017 at 12:31 AM, René Scharfe <l.s.r@web.de> wrote:
Show 54 quoted lines
> 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.
Yes, not to beat this point to death, but to clarify since we still seem to be talking about different things:
I'm not saying it isn't fuzzy and inaccurate, I'm saying there's a use-case for human readable output where saying e.g. "somewhere New York-ish" is more useful than nothing, even given summer time I'm still going to know approximately what timezone it is, more so than the offset number.
And that is, I would argue, the best thing to do when the user is via %Z asking for a human-readable timezone-ish given a commit object, which only has the offset.
Show 5 quoted lines
> 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.
Yes I think if we're going down the road of providing some human-readable version of the offset this is near-useless since almost nobody using Git is going to know these by heart.
Show 10 quoted lines
>> 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.
It could be done by accepting that you're not going to get a perfect solution but one that's good enough to aid the humans currently reading the currently only numeric output.
My use-case for this is having colleges all over the world who create commits using different time offsets. It's simply easier to at a glance realize what office someone is in if "git log" is printing city names in/near those timezones, even if none of those cities are where those people are located.