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

From: René Scharfe <l.s.r@web.de>
Date: Jun 14, 2017, 19:36 UTC
Message-ID: <e9260c40-c49f-d7f6-70c2-a28c1b3104a2@web.de>
In-Reply-To: <20170614111043.xlfsgclbyrqektb3@sigill.intra.peff.net>

Am 14.06.2017 um 13:10 schrieb Jeff King:

Show 25 quoted lines

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