On Tue, Jul 21, 2020 at 07:51:56PM +0200, Laslo Hunhold wrote:
> On Sun, 19 Jul 2020 09:37:31 -0700
> Jeremy <jer_AT_jer.cx> wrote:
>
> Dear Jeremy,
>
> I wrote this this mail yesterday, but the mailing list had some
> technical problems, so I'm resending it.
>
> > stat(3)'s mtime is in local time while REQ_MOD is in GMT.
> > This patch translates mtime to GMT before comparing to REQ_MOD.
>
> It's sadly even more complicated than that, and I must admit that I
> have not yet come up with a good portable solution. As so many other
> things, Posix time handling is a big mess.
>
> When we parse the If-Modified-Since-Header in line 529 using
> strptime(), we store the information correctly in the broken down time
> representation. The broken down representation in this case has no
> regard for timezones and just naïvely stores the individual fields that
> are given in the timestamp (i.e. no timezone given for strptime yields
> no timezone information in the broken down representation).
>
> When we then later call mktime(&tm), the function interprets the
> timestamp as local time (!) and not as UTC. The st.st_mtim.tv_sec is
> fine, though, as this just represents the seconds since epoch.
>
> So the central problem is not the stat-result but the fact that our
> mktime() interprets the timestamp as local time. There is a function
> timegm() that does just that (take a broken down time representation,
> interpret it as UTC and return its unix time), but it's not
> standardized.
>
> One idea could be to just go with the flow and parse the time
> 1970-01-01 00:00:00 UTC as a string using strptime into a broken down
> representation and then drop it into mktime, which erroneously
> interprets it also as local time, yielding a non-zero value, which we
> can then just use as an offset (negative or positive, which is not a
> problem, as time_t is signed). The real issue with this approach,
> though, is the fact that this might not properly respect
> post-1970-timezone changes (e.g. what happened in Russia in the last
> decade).
>
> Another idea could be to set the timezone to UTC using tzset() during
> program initialization. The (dis-?)advantage is that access logs would
> only give the times in UTC and not local time.
>
> What do you think (also _AT_Hiltjo)?
>
> With best regards
>
> Laslo
>
I would use timegm(). It is not in POSIX, but it does exactly the right thing.
It should be available in glibc, musl and on all BSDs.
Hacking around mktime to get the correct result has some gotcha's. I would not
do it.
The latest patch from Jeremy looks good to me.
--
Kind regards,
Hiltjo
Received on Tue Jul 21 2020 - 20:38:41 CEST