Re: Timezone with DATE_STRFTIME

From: John Keeping <john@keeping.me.uk>
Date: Feb 8, 2016, 15:46 UTC
Message-ID: <20160208154643.GQ29880@serenity.lan>
In-Reply-To: <20160208152858.GA17226@sigill.intra.peff.net>

On Mon, Feb 08, 2016 at 10:28:58AM -0500, Jeff King wrote:

Show 36 quoted lines

> On Mon, Feb 08, 2016 at 02:33:17PM +0000, John Keeping wrote:
> 
> > I have just noticed that with DATE_STRFTIME, the timezone in the output
> > is likely to be incorrect.
> > 
> > For all other time formats, we print the string ourselves and use the
> > correct timezone from the input, but with DATE_STRFTIME strftime(3) will
> > always use the system timezone.
> 
> You mean here that the "%z" formatting will not be correct, right?
> AFAICT the time shown is generally correct for the original of the
> author, and we simply need to communicate the zone to strftime.
> 
> Taking the current tip of master, for instance, I get:
> 
>   $ for i in \
>       default \
>       local \
>       "format:%H:%M %z" \
>       "format-local:%H:%M %z"; do
>             git log -1 --format=%ad --date="$i" ff4ea6004
>     done
>   Fri Feb 5 15:24:02 2016 -0800
>   Fri Feb 5 18:24:02 2016
>   15:24 +0000
>   18:24 +0000
> 
> You can see that my system is in -0500, three hours ahead of the author.
> And as expected, strftime shows the time in the original author's
> timezone. The %z information is totally bogus, but I don't think it has
> anything to do with the system time. It is simply that we don't provide
> it (...but having just looked at _your_ local timezone from your email,
> I can guess how you got confused :) ).
> 
> So I think the fix is probably just that we need to feed the zone
> information to strftime via the "struct tm".

If "struct tm" had a standard field for that...

Obviously "struct tm" does have a field for the offset (which is how we end up in +0000 above, because our "struct tm" comes from gmtime(3)), but it's not standardized so I don't think we can rely on it.

AFAICT the only way to pass the timezone into the C library time functions is via $TZ or the global "timezone" variable, but from looking at a couple of implementations I don't think strftime() will actually look at those (the timezone is instead embedded when the "struct tm" is generated).