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

[Tim Peters]

[Tim]
>> is_dst remains necessary to distinguish between ambiguous local times,
>> just as Chris states:

[Lennart]
> But with the current implementations, those do not exist.

Of course they exist.  That's a plain fact about how most timezones work.

> datetime explicitly and intentionally assume that 1 day always is 24 hours.

The "naive time" model assumes that, but not everything in datetime
follows the "naive time" model.  For example, just a short time ago I
explained to you, at considerable length, that zone conversions are
(intentionally) viewed as operations _outside_ the "naive time" model.
Like manually changing a mechanical wrist watch when DST changes.  The
watch follows "naive time" before and after you change it, not _while_
you're changing it.

> Hence, in the datetime universe, local times can not be ambiguous,

Repeating a counterfactual won't increase its truth value ;-)(
Ambiguous times exist on a mechanical wrist watch too.

>> Not so.  It can easily (albeit rarely) arise in cases of pure timezone
>> conversions.  Conversions have nothing to do with arithmetic.  If I
>> convert a time in zone X to a time in zone Y that lands in an
>> ambiguous span in zone Y, without the conversion _also_ setting an
>> is_dst flag in the destination, it's impossible to reliably convert
>> the time in zone Y back to zone X again.

> No, you just consistently pick one of the two times in both
> conversions to and from and it will roundtrip just fine.

Nope, not even if we insist that X can only be UTC.  For example, when
US Eastern Daylight ends, 5:30 and 6:30 UTC _both_ convert to 1:30
EST.  But 1:30 EST can convert back to only one of those.  If you
"consistently pick", say, the earliest, then 5:30 UTC is what you get.
Then the result of round-tripping 6:30 UTC to-and-back-from US Eastern
is dead wrong (5:30 UTC is not 6:30 UTC, not even in "naive time" ;-)
).  If you "consistently pick" 6:30 UTC instead, then round-tripping
starting from 5:30 UTC is dead wrong.

But I'm unclear why an example should be necessary.  "Ambiguous time"
_means_ there's a time spelling in one zone that has _at least_ two
spellings in another zone. In any such case, it should be obvious on
the face of it that round-tripping starting _from_ the zone with more
than one spelling can't possibly always work, unless additional info
is recorded to say _which_ spelling we started with.  If there's also
_at most_ two equivalent spellings, then "a flag" (1 more bit) is both
necessary and sufficient.