[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|NOTABUG                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> ---
> I don't see a bug here. The input to mktime is ambiguous, since two periods of standard time are plausible, either the one at -11 (e.g, from 2011-04-02 to 201-09-24) or the one at +13 (e.g., from 2012-04-02 to 2012-09-30).

This is NOT THE CASE. The input time is an unambiguous time *outside* of the
zone transition cut. The nonexistent (thus ambiguous) range is 2011-12-30
00:00:00 to 2011-12-30 23:59:59. The requested time is 2011-12-31 01:00:00, but
specified as "the time that would have been 00:00:00 if DST were not active".

Note that, even if it were handled as being in DST, this would *still* be
outside of the zone transition cut, so the bug shouldn't be a matter of
crossing the cut as an intermediate calculation. It's probably glibc using the
adjacent rule across the cut, rather than the adjacent opposite-DST-state rule
in spring, to adjust for tm_isdst not matching the DST state in effect at the
requested time.

> The right thing to do is to set tm_isdst to -1 if you don't know the actual value.

Setting tm_isdst=-1 is semantically completely different from setting
tm_isdst=0. tm_isdst=0 does not mean "we don't know if it's DST or not". It
means "we are asking mktime to normalize a time specified in terms of whether
it's given in DST or not, to the actual state of DST at that time". It would
arise in situations like requesting "now - 93 days" on April 2.

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