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

From: Jeff King <peff@peff.net>
Date: Jun 15, 2017, 05:42 UTC
Message-ID: <20170615054209.yfucmiq3pghxu76j@sigill.intra.peff.net>
In-Reply-To: <f80aa20c-dd7e-41e6-f35f-5c633c169732@web.de>

On Thu, Jun 15, 2017 at 01:03:29AM +0200, René Scharfe wrote:

Show 15 quoted lines

> Am 14.06.2017 um 23:04 schrieb Johannes Schindelin:
> > On Wed, 14 Jun 2017, René Scharfe wrote:
> > 
> >> Does someone actually expect %z to show time zone names instead of
> >> offsets on Windows?
> > 
> > Not me ;-)
> > 
> > I cannot speak for anyone else, as I lack that information, though.
> 
> Before the patch %z would always expand to +0000 on Linux and to the
> name of the local time zone on Windows, no matter which offset was
> actually given.  So it was broken in either case (even though it got
> at least some aspects right by accident for some commits).  Based on
> that I'd think handling %z internally should be OK.

I agree.

Show 8 quoted lines

> But there's more.  strftime on Windows doesn't support common POSIX-
> defined tokens like %F (%Y-%m-%d) and %T (%H:%M:%S). We could handle
> them as well.  Do we want that?  At least we'd have to update the
> added test that uses them..
> 
> Here's the full list of tokens in POSIX [1], but not supported by
> Windows [2]: %C, %D, %F, %G, %R, %T, %V, %e, %g, %h, %n, %r, %t, %u
> plus the modifiers %E and %O.

I don't have a real opinion on that. The point of adding strftime was always to give the user access to whatever their system supports. In particular "%c" which we cannot emulate ourselves.

If people want support for those other things on platforms that don't have it, I have no real objection. But I also don't know that it's worth spending time on if nobody is asking for it.

-Peff