On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore <p.f.moore@gmail.com> wrote:

The semantic issue here is that users typically say "01:45" and
it never occurs to them to even think about *which* 01:45 they mean.
So recovering that extra information is hard (it's like dealing with
byte streams where the user didn't provide details of the text
encoding used). Once we have the extra information, though, doing
conversions is just a matter of applying a set of rules.

It is slightly more complicated than that. There are locations (even in the US, I've heard)

where clocks have been moved back for reasons other than DST. I described one such

example in my earlier post [1]. On July 1, 1990, at 2AM, the people of Ukraine celebrated

their newly acquired independence by moving their clocks back to 1AM thus living

through "1990-07-01T01:45" local time twice. This happened in the middle of summer and

daylight savings time was in effect before and after the transition, so you cannot use isdst

to disambiguate between the first and the second "01:45".

On the other hand, these rare events are not that different from more or less regular DST

transitions. You still have either a non-existent or ambiguous local times interval and

you can resolve the ambiguity by adding 1 bit of information. The only question is what

should we call the flag that will supply that information? IMO, "isdst" is a wrong name

for dealing with the event I described above.

[1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html