>>>>> On Fri, 2 Jun 2017, Jeff King wrote: > On Fri, Jun 02, 2017 at 07:25:43PM +0200, René Scharfe wrote: >> On Linux "%z %Z" is expanded to "+0200 CEST" for me, while on Windows I >> get "Mitteleurop▒ische Sommerzeit Mitteleurop▒ische Sommerzeit". (That >> "▒" is probably supposed to be an "ä".) POSIX requires +hhmm or -hhmm >> format for %z, and for %Z is to be "Replaced by the timezone name or >> abbreviation". Actually, the POSIX definition for %Z continues: "or by no bytes if no timezone information exists." So also returning an empty string would be compliant (but maybe not very helpful). >> I'd say "GMT+0200" etc. is a nice enough timezone name, i.e. having %Z >> resolve to the same as %z plus a literal prefix of "GMT" should at least >> not be wrong. > I thought that, too, but I think it is wrong based on my understanding > of how $TZ is parsed. There something like "EDT-4" means "call this EDT, > and by the way it is 4 hours behind GMT". > So what you're proposing isn't wrong per se, but your notation means > something totally different than what similar-looking notation looks > like on the $TZ end, which is bound to create confusion. I agree that GMT+0200 could be misleading. But what about resolving %Z the same as %z in the case of the author's time zone, as was suggested earlier? It is supposed to be human-readable output, or do we expect that someone would use the %Z output and e.g. plug it back into their TZ? >> Alternatively we could have a lookup table mapping a few typical offsets >> to timezone names, but e.g. handling daylight saving times would >> probably be too hard (when did that part of the world switch in the >> given year? north or south of the equator?).. IMHO maintaining such a local table of timezones won't fly. > Right, I don't think the mapping of zone to offset is reversible, > because many zones map to the same offset. If I tell you I'm in -0500, > even just in the US that could mean Eastern Standard Time (winter, no > DST) or Central Daylight Time (summer, DST). Not to mention that other > political entities in the same longitude have their own zones which do > DST at different times (or were even established as zones at different > times; historical dates need to use the zones as they were at that > time). Same here, my +0200 offset could be anything of CAT, CEST, EET, IST, SAST, or WAST, according to IANA timezone data. It's a one-directional mapping, and there's no way to get the author's /etc/localtime info (or whatever its equivalent is on other systems) back from the offset stored in the commit. A timezone name may not even exist at all for a given [+-]hhmm offset. Ulrich