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

[Ulrich Mueller]

> On Thu, 15 Jun 2017, René Scharfe wrote:

> Callers can opt out for %Z by passing NULL as timezone name.  %z is
> always handled internally -- this helps on Windows, where strftime would
> expand it to a timezone name (same as %Z), in violation of POSIX.
> Modifiers are not handled, e.g. %Ez is still passed to strftime.

POSIX would also allow other things, like a field width:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html

$ date '+%8z'
+200

(But I believe that's not very useful, and supporting it might require
duplicating much of strftime's code.)

> Changes from v1:
> - Always handle %z internally.

Minor nitpick: Shouldn't the comment in strbuf.h be updated to reflect
that change?

> + * Add the time specified by `tm`, as formatted by `strftime`.  `tz_offset`
> + * and `tz_name` are used to expand %z and %Z internally, unless `tz_name`
> + * is NULL.  `tz_offset` is in decimal hhmm format, e.g. -600 means six
> + * hours west of Greenwich.

Ulrich

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

[Ulrich Mueller]

> On Tue, 13 Jun 2017, René Scharfe wrote:

> Am 12.06.2017 um 21:02 schrieb Ævar Arnfjörð Bjarmason:
>> 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.

And sometimes it would be impossible since DST rules differ between
hemispheres. For example, there is Europe/Berlin vs Africa/Windhoek,
or America/Halifax vs America/Santiago.

> 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. :)

Yeah, that would ensure complete confusion. :) You'd have "Quebec"
for -0400 whereas the city of Quebec is in zone -0500. Similar for
"Lima" denoting +1100.

> Also there are no names for zones that have an offset of a fraction
> of an hour.

There are also zones like Pacific/Tongatapu which have +1300 (and +1400
in summer).

All in all I think that Jeff's suggestion makes most sense: Expand %Z
to the timezone name for the -local case, when the name is readily
available. Otherwise, expand it to the empty string.

Ulrich

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

[Ulrich Mueller]

> On Mon, 12 Jun 2017, Ævar Arnfjörð Bjarmason wrote:

> On Mon, Jun 12, 2017 at 5:12 PM, Junio C Hamano  wrote:
>> René Scharfe  writes:
>>> Yes, or you could look up a time zone name somewhere else -- except we
>>> don't have a way to do that, at least for now.
>> 
>> Is that only "for now"?  I have a feeling that it is fundamentally
>> impossible with the data we record.  When GMTOFF 9:00 is the only
>> thing we have for a timestamp, can we tell if we should label it as
>> JST (aka Asia/Tokyo) or KST (aka Asia/Seoul)?

> It's obviously not perfect for all the reasons mentioned in this
> thread, but we already have a timezone->offset mapping in the
> timezone_names variable in date.c, a good enough solution might be to
> simply reverse that lookup when formatting %Z

That cannot work, because there is no unique mapping from offset to
timezone name. For a given offset there may be several timezone names,
or no name at all. (For example, if I decide to commit with my local
mean time which has an offset of +0033 then there won't be any
timezone name at all.)

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

> We could also simply replace "%Z" with the empty string, as the the
> POSIX strftime() documentation allows for:
> http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html
> ("Replaced by the timezone name or abbreviation, or by no bytes if no
> timezone information exists.").

IMHO the two viable possibilities are the empty string, or the same
information as for %z. But this has been said before in this thread.

tzdata2017b has the following data in its "etcetera" file, the last
column being the timezone name:

   Zone Etc/GMT  0  -GMT

   Zone Etc/GMT-14  14  -+14
   Zone Etc/GMT-13  13  -+13
   [...]
   Zone Etc/GMT+12 -12  --12

This would be at least some rationale for converting %Z to [+-]hhmm,
i.e., the same as for %z. (One could even think about [+-]hh if the
minutes part is zero, but this already looks like over-engineering
to me.)

Ulrich

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

[Ulrich Mueller]

> On Sat, 3 Jun 2017, René Scharfe wrote:

> + case 'Z':
> + strbuf_addstr(_fmt, tz_name);

Is it guaranteed that tz_name cannot contain a percent sign itself?

Ulrich

Re: git-2.13.0: log --date=format:%z not working

[Ulrich Mueller]

> On Fri, 2 Jun 2017, Jeff King wrote:

> The remaining question is whether we want to care about preserving the
> system %Z for the local-timezone case.

No strong preference here. Maybe go for consistency, and have %Z
always return the same format (either empty, or same as %z). That
would at least prevent surprises when users switch from format-local
to format.

Ulrich

Re: git-2.13.0: log --date=format:%z not working

[Ulrich Mueller]

> 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

git-2.13.0: log --date=format:%z not working

[Ulrich Mueller]

The following commands work as expected (using commit b06d364310
in the git://git.kernel.org/pub/scm/git/git.git repo as test case):

$ export TZ=Europe/Berlin
$ git --no-pager log -1 --pretty="%ad" --date=iso b06d364310
2017-05-09 23:26:02 +0900
$ git --no-pager log -1 --pretty="%ad" --date=iso-local b06d364310
2017-05-09 16:26:02 +0200

However, if I use explicit format: then the output of the time zone is
wrong:

$ git --no-pager log -1 --pretty="%ad" --date="format:%F %T %z" b06d364310
2017-05-09 23:26:02 +
$ git --no-pager log -1 --pretty="%ad" --date="format-local:%F %T %z" b06d364310
2017-05-09 16:26:02 +

I would expect the output to be the same as in the first two examples.