Timezone with DATE_STRFTIME

Timezone with DATE_STRFTIME

[John Keeping]

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.

Re: Timezone with DATE_STRFTIME

[Jeff King]

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

-Peff

Re: Timezone with DATE_STRFTIME

[Jeff King]

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

> So I think the fix is probably just that we need to feed the zone
> information to strftime via the "struct tm".

Ugh, I forgot how horrible the strftime interface is.

There is no zone information in "struct tm". It gets pulled from the
magic global variable "timezone", and you're supposed to use "tzset" to
set it up. We don't. POSIX says:

  Local timezone information is used as though strftime() called
  tzset().

but on my system that does not seem to be the case. At any rate, our
options are:

  1. Trying to munge a global variable with the timezone information we
     have just for the duration of our strftime call.

or

  2. Admit that strftime's "%z" is crap, and tell people not to use it.

I think I am leaning towards the latter, though unfortunately I don't
think there is a way to find out the author's timezone via
--date=format, then. Perhaps it should default to "--date=format-local:".

-Peff

Re: Timezone with DATE_STRFTIME

[John Keeping]

On Mon, Feb 08, 2016 at 10:28:58AM -0500, Jeff King wrote:
> 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).