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

[Tim Peters]

[Aahz]
> It sure sounds like you're saying that the DateTime module can't handle
> timezone conversions at all.

Nope, overall it does very well.  Go back to the original msg:  there are
glitches during two hours per year, for tzinfo classes that try to model
both daylight and standard time.  That's it.

> If it can, I don't understand what extra ambiguity (in human terms)
> is introduced by DST, as long as there are no round-trip conversions.

Sorry, I can't explain this any better than it's already been explained.
There's no ambiguity in EST or EDT on their own, there is ambiguity twice a
year in a single class that tries to combine both.

> ...
> I'm confused: are you saying that Guido's calendar doesn't get
> internally converted to UTC?

I'd say that whether it is is irrevelant to the example.  Just as there are
hours in UTC that can't be spelled unambiguously in US Eastern, there are
hours in US Eastern than can't be spelled unambiguously in any other hybrid
(daylight+standard) time zone.  These problems have to do with the target
time system, not with the originating time system.

> If not, then the chart from your message starting this thread doesn't
> apply, because here you're talking about converting from wall clock to
> wall clock, which I think is a conversion that makes no sense

Of course it does:  at any moment, you can call Guido, and if he answers the
phone <wink> you can ask him what his wall clock says.  He doesn't have to
convert his local time to UTC to answer the question, and neither do you.
There's "almost never" a problem with this, either.

> -- that perhaps would be a suitable occasion for an exception.

It seems to depend on the app a person has in mind.

> If Guido's appointment does get converted to UTC, then there's always a
> sensible (if possibly ambiguous) conversion to wall time, and if he
> looks at his calendar, he should be able to see if his appointment got
> converted to UTC correctly.

Fine, pretend Guido lives in Greenwich and UTC is his local time.  The
ambiguity remains, and it doesn't matter whether Guido can detect it:  by
hypothesis, *you're* the one looking at his calendar, and in your local
time.  If an appointment then shows up as starting at 1:00 in your local
time on the day daylight time ends for you, you're most likely to believe
that's your daylight time (assuming you live in the US and in an area that
observes DST).  It may or may not be in reality, and whether that matters
depends on the use you make of the information.