[Bug time/31144] mktime: returns clock for UTC with isdst=1

["eggert at cs dot ucla.edu" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31144

--- Comment #4 from eggert at cs dot ucla.edu ---
(In reply to Florian Weimer from comment #3)
> We already scan the entire tables while loading the time zone data, so we
> could make a note if we have seen any DST hints, and if there are none
> present, we could fail as before for tm_isdst > 0. We also don't know how
> the tz project will model the introduction of DST if a zone changes
> introduces DST for the first time, so the synthetic offset might well be
> wrong.
Yes, that could be done and shouldn't be hard to do. If so, we'd need to
consult the trailing TZ string as well as the tm_isdst flags in the binary
tables.

However, failing would not be good, as we already learned when we put in code
to have mktime fail. This is because a lot of code expects mktime to succeed
unless the resulting time_t would be out of range. Better would be to ignore
tm_isdst in timezones that have never observed tm_isdst.

> We also don't know how the tz project will model the introduction of DST
> if a zone changes introduces DST for the first time,
> so the synthetic offset might well be wrong.
There's no way in general to determine a synthetic offset. For example,
America/St_Johns observed 1-hour DST in summer 1987 and 2-hour DST in summer
1988. If mktime is given a timestamp in January 1988 with tm_isdst=1 should it
use a 1-hour offset or a 2-hour offset? That would depend on whether the
timestamp was computed from in the previous summer but adding a few months, or
from the next summer but subtracting a few months. Both scenarios are
plausible.

One possibility is that glibc mktime could use the incoming tm_gmtoff as a hint
as to what synthetic offset to use. If the incoming tm_gmtoff is one of the DST
offsets that appears in the TZif's binary data or TZ string, then mktime could
use that offset. Although this would in theory rely on undefined behavior
(tm_gmtoff might be uninitialized), in practice it would likely work better
than what glibc does now. If this possibility were implemented lazily it
shouldn't slow down the typical mktime case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.