On Mon, Jun 12, 2017 at 8:20 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Mon, Jun 12, 2017 at 07:53:21PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> >> 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.
>
> I think the main problem is that the mapping isn't just "JST->+0900".
> It's a set of rules that depend on the specific time being converted. So
> it's true that at some time t, +0900 may mean JST or KST or whatever.
> But at a different time, those time zones will map to a different
> offset.
To the extent that it doesn't map correctly (e.g. due to summer time)
that's already a bug/understood limitation in the fuzzy TZ parser in
date.c, isn't it (dating back to Linus's "In my world, it's always
summer" comment in 89967023da).
> So I think at best this is semantically confusing (the author was not in
> JST, but just happened to be in a time zone that maps to the same thing
> at that moment, and any attempt to extrapolate their zone at another
> time is going to be wrong). And at worst the output of "git log" is
> going to show the same user flip-flopping between zones as their commits
> move around with respect to the (politically determined) zone changes.
> For instance in my time zone I'd shift between EST and CST twice per
> year due to DST. My real time zone is EST5EDT, or better still,
> America/New_York (I don't live there, but the Olson database carves up
> regions based on the most populous city in the zone).
I think everyone in this thread disagrees with what I think makes
sense for %Z, and I'm not going to argue the point, I just thought I'd
chime in because it seemed to me that the discussion had missed the
mapping we had in the timezone_names variable.
But FWIW and just to (I think fairly) summarize, here's where we differ.
You (and others) think that unless we can actually show the user's
time zone as it appeared on their machine %Z shouldn't show anything
at all, since it would be confusing. Fair enough.
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@xxxxxxxxx>
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@xxxxxxxx>
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.
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 :)