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é