[Zope3-dev] RE: [Python-Dev] Holes in time

[Tim Peters]

[Aahz]
> ...
> Hmmm....  Maybe we don't have an argument.

We don't, unless you're claiming there isn't ambiguity at DST switch points.

> What *does* the current implementation do when it hits the witching
> hour of DST->ST?

Please read the original msg again.  Nothing that followed has been of much
help, and I've really had nothing new to say since then -- it was all there
at the start (including the answer to this question).

> So far, I've been saying that it should return 1:MM twice when converting
> from UTC; if it already does that, I'm fine.

It doesn't now, but I believe it will be reasonably cheap to do so, and
that's what Guido wants it to do too.  Provided that's the defined and
documented behavior, fine by me too.  Thanks for pushing for it!  (Right or
wrong, it fosters the illusion of consensus <wink>.)

> ...
> The only case where I've advocated raising an exception was attempting
> to convert a pure wall clock time to any timezone-based time.

The datetime module doesn't have a class named "PureWallClockTime" <wink>.
Seriously, the original msg posed focused questions about how a specific
class method should act in its debatable endcases, and anything beyond that
is out-of-scope for me here.

> (As in the case of Guido's calendar entries.)  That would raise an
> exception for all times, not just DST change days.

Under the agreement, Guido's calendar entries will display as 1:MM in this
case, if a programmer uses datetimetz.astimezone() to convert them.  It will
never raise an exception merely for "I don't think you should do that"
reasons, or even for "but the hour can't be spelled unambiguously in your
time zone" reasons.

> ...
> I'm starting to think that the current design is incomplete for tzinfo
> classes that model internal DST changes.

Yes.  Without a moral equivalent to struct tm's tm_isdst flag (which
datetime does not have), it's necessarily incomplete, and that has
consquences for two (and only two) hours per year in hybrid
(standard+daylight) tzinfo classs.  One consequence seems trivial (assigning
"a meaning" to the non-extant 2:MM local hour at DST start); the importance
of the other (an unspellable in local time hour at DST end) varies by app,
and seemingly by what mood someone is in when they think about it.