Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

["René Scharfe" <l.s.r@web.de>]

Am 14.06.2017 um 13:10 schrieb Jeff King:
> On Wed, Jun 14, 2017 at 12:57:06PM +0200, Johannes Schindelin wrote:
>> But even then, it fails in t0006 on Windows with this error:
>>
>> -- snip --
>> ++ eval 'diff -u "$@" '
>> +++ diff -u expect actual
>> --- expect      2017-06-14 10:53:40.126136900 +0000
>> +++ actual      2017-06-14 10:53:40.171146800 +0000
>> @@ -1 +1 @@
>> -1466000000 +0200 -> 2016-06-15 14:13:20 +0000 (UTC)
>> +1466000000 +0200 -> 2016-06-15 14:13:20 UTC (UTC)
> 
> Ugh, I was worried about that some systems might display timezones
> differently (that's why I _didn't_ check %Z in the EST5 case). But I
> must admit this was not an incompatibility I was expecting. It looks
> like your system strftime() turns %z into "UTC". POSIX says:
> 
>    %z
>      Replaced by the offset from UTC in the ISO 8601:2000 standard format
>      (+hhmm or -hhmm), or by no characters if no timezone is
>      determinable.
> 
> So it seems like the mingw strftime is violating POSIX. I don't see an
> easy solution beyond marking this as !MINGW. Though if we wanted a
> partial test, we could test %z and %Z separately.

Hmm.  The patches currently either let strftime handle both %z and %Z
(in the local case) or handle both internally.  Perhaps we need a third
option, namely to handle %z internally in all cases for systems whose
implementation violates POSIX?  Nah, it would be easier to always handle
%z internally.  Any downsides?  Does someone actually expect %z to show
time zone names instead of offsets on Windows?

René