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

[Tim Peters]

[Aahz]
> So there's ambiguity.  So what?

That was my question in the orginal msg, and hasn't changed:  there are
problems at two points, they're inherent to the current design (so can't be
wished away), but the current implementation could change what it does in
these cases -- what do people want to see done?

> What I don't understand is why it's a problem.

It depends on the app; like any other "surprise", depending on the app it
may never be noticed, or may cost lives, or anything in between.  Both you
and Marc-Andre have been disturbed enough at the *possibilities* for bad
consequences to claim that such cases should raise exceptions (although you
seem to spend more energy arguing that there's no problem at all <wink>).
Guido made a case on the other side, that once-a-year exceptions unlikely to
be caught by testing carry a different kind of real risk.

> More precisely, I see these problems existing in the absence of
> computers, and I don't see where creating a Python DateTime class
> creates any more problems or makes the existing problems worse --

I don't think any of that matters:  an API needs to define what it does.

> as long as you don't try to convert between timezones in the absence
> of sufficient information.

The current design doesn't allow the possibility for sufficient information
in these cases.  One plausible response to that is to insist that the
current design is fatally flawed.  Another is to shrug "so it goes", and
define what it does do, as best as can be done.

>> ... at any moment, you can call Guido, and ...

> But that's not a conversion.

?  It's clearly a way to convert your local time to Guido's local time.  The
only real difference is that when you call Guido at 6:30 UTC on the day
daylight time ends for him, and he replies "oh, it's 1:30 here", you have
the further possibility to ask him whether he meant 1:30 EDT or 1:30 EST.
Apart from that, dt.astimezone(Eastern) will give you answers identical to
his every time you try it (assuming you start with dt.tzinfo=Pacific (from
US.py), that you still live in the Pacific time zone, and that you and Guido
both scrupulously adjust your clocks at the politically defined DST
transition times).

> ...
> From my POV, this problem exists regardless of whether a computer
> mediates the transaction.

Of course it does. but that doesn't excuse Python from defining its own
behavior in these cases.  Apart from that, the consequences of ambiguity in
a program are often called "bugs", but the consequences of ambiguity in real
life are merely called "real life" <0.9 wink>.

> The most likely error (if one happens) is that someone shows up an
> hour early for the appointment, and presumably that person knows
> that the day is a DST transition.

This sounds like you don't want it to raise an exception, then.