From: René Scharfe Date: Wed, 14 Jun 2017 19:36:38 GMT Subject: Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13) Message-ID: In-Reply-To: <20170614111043.xlfsgclbyrqektb3@sigill.intra.peff.net> 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é