[tz] Java & Rearguard

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Sat Jun 1 20:07:46 UTC 2019


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.


More information about the tz mailing list