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

[Jeff King <peff@peff.net>]

On Wed, Jun 14, 2017 at 12:57:06PM +0200, Johannes Schindelin wrote:

> Hi Junio,
> 
> On Tue, 13 Jun 2017, Junio C Hamano wrote:
> 
> > * rs/strbuf-addftime-zZ (2017-06-10) 2 commits
> >  - date: use localtime() for "-local" time formats
> >  - strbuf: let strbuf_addftime handle %z and %Z itself
> > 
> >  As there is no portable way to pass timezone information to
> >  strftime, some output format from "git log" and friends are
> >  impossible to produce.  Teach our own strbuf_addftime to replace %z
> >  and %Z with caller-supplied values to help working around this.
> > 
> >  Will merge to 'next'.
> 
> Hold on. Have you tried to build this branch?
> 
> -- snip --
>     CC date.o
> date.c:63:36: error: unknown type name ‘timestamp_t’
>  static struct tm *time_to_tm_local(timestamp_t time)
>                                     ^
> date.c: In function ‘show_date’:
> date.c:211:8: error: implicit declaration of function ‘time_to_tm_local’
> [-Werror=implicit-function-declaration]
>    tm = time_to_tm_local(time);
>         ^
> date.c:211:6: error: assignment makes pointer from integer without a cast
> [-Werror=int-conversion]
>    tm = time_to_tm_local(time);
>       ^
> cc1: all warnings being treated as errors
> -- snap --
> 
> I would expect this to be rebased *at least* to dddbad728c9 (timestamp_t:
> a new data type for timestamps, 2017-04-26).

Yeah, the timestamp_t mentions are from my patch (the top one). I built
it applying René's on the current master and then building on top. I
suspect Junio didn't test it in isolation, but only merged to "pu",
where it would be OK.

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

-Peff