On 2019-06-01 10:53, Paul Eggert wrote:
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.
Thanks for the clarification, and I could see where, for ambiguous summer time periods, the state of tm_isdst could be used as input to hint to mktime which output was desired. Where tm_isdst is also ambiguous, that is no help for input or output, and from other discussions, an earlier/later input selection (and output indicator) would be desirable. [North American electrical power generation, load, transmission, and distribution systems operate with local times to accommodate local time peak/non-peak/off-peak, holiday, and weekend power schedules and tariffs (which are remarkably consistent across local time zones), and the systems have to be able to handle each local time zone's ambiguous hours (where used), with the second instance usually labelled something like e.g. 2*, and the consequent 25 and 23 hour days. APIs that don't allow for and handle such local time variations have to be considered defective!] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.