[Datetime-SIG] What's are the issues?

[Tim Peters]

[Lennart]
> Are you saying that conversions between time zones are wrong!?

I already explained everything conversions are known to do correctly,
known not to do correctly, and the existing mechanisms available if
anyone cares enough to repair the latter cases.

>> Silly me - I thought you were asking about DST conversions

> A don't view a DST change as a conversion, perhaps that's the
> communication issue here.

Perhaps instead of typing the suggestive-but-literal-nonsense "about
DST conversions" before I should have typed something like "about the
complications DST transitions can create for timezone conversions"
(which was part of the topic of the message at the start of all this).

DST is relevant to conversions when the source and/or destination
times are "close enough" to DST transition points in their respective
time zones.  The current implementation mimics local clock behavior in
the _destination_ zone in such cases.  The current implementation has
no way to know which time in the _source_ zone was intended in cases
of times that are ambiguous in the source zone.

>> Here's you. talking about conversion when the base UTC offset changes:

>>> This will be handled in the exact same way as DST changes, and if
>>> this is incorrect, then reasonably, so is the DST handling.
>>> What is "incorrect" here is of course a matter of opinion.

> No, that's not a conversion, that ooccurs within the same time zone.

I agree,  See above.  I used the literally senseless "DST conversion"
as a shorthand for a wall of text I didn't think should still be
necessary ;-)

As you said, exactly the same kinds of "missing time" and "repeated
time" irregularities can occur regardless of the cause of the
irregularities.  It seems clear now you had only arithmetic in mind,
while I had only conversions in mind, but the irregularities are
potential issues for any way whatsoever of producing a datetime
(whether as the result of arithmetic, the result of a conversion
operation, the result of parsing a string, the result of combining
separate date and time objects into a single datetime object, ...).
All possible causes of irregularities (including DST transitions) are
potential headaches for all possible ways (including conversions &
arithmetic) of creating a datetime object.

Local DST transitions and local transitions due to the base UTC offset
changing create exactly the same kinds of headaches.  In the current
implementation of conversions, irregularities in the local clock are
reliably tracked in the destination zone only when the irregularity is
caused by a destination zone DST transition (see earlier msg for
details about why that's the case).

And before anyone feels compelled to point it out for the 10
thousandth time ;-), yes, single-zone arithmetic was intentionally
designed to ignore all possible sources of irregularities.