Re: [hackers] [quark][PATCH] fix for NOT_MODIFIED being sent in non-GMT timezone

From: Laslo Hunhold <dev_AT_frign.de>
Date: Mon, 20 Jul 2020 08:54:11 +0200

On Sun, 19 Jul 2020 09:37:31 -0700
Jeremy <jer_AT_jer.cx> wrote:

Dear Jeremy,

> 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
Received on Mon Jul 20 2020 - 08:54:11 CEST