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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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é



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]