Brian Inglis wrote:
Every time zone that has seasonal offset changes has periods per year where local time does not exist (spring forward) and ambiguous duplicated local time periods (fall back). Or am I missing something different?
Brandon Smith said that his software had trouble with transitions where (1) tm_isdst==0 before and tm_isdst>0 after the transition, and (2) the clock moves backward so there are ambiguous timestamps before the transition. The implication was that this was a new situation, and so there's some justification in modifying the data to avoid it. My point was that it's not a new situation, in that other such transitions have been in the database for decades. This is related to Robert Elz's point that mktime is not up to handling arbitrary ambiguous timestamps. Although mktime can handle ambiguous timestamps where tm_isdst changes, it can't handle ambiguous timestamps where tm_isdst is the same before and after the transition. By "can't handle" I mean that mktime's caller has no control over which of the ambiguous timestamps is returned by mktime, and the caller isn't even informed whether the timestamp is ambiguous.