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

[Aahz]

On Fri, Jan 03, 2003, Tim Peters wrote:
> [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?

Hmmm....  Maybe we don't have an argument.  What *does* the current
implementation do when it hits the witching hour of DST->ST?  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.

>> 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.

The only case where I've advocated raising an exception was attempting
to convert a pure wall clock time to any timezone-based time.  (As in
the case of Guido's calendar entries.)  That would raise an exception
for all times, not just DST change days.

>> 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.

I'm starting to think that the current design is incomplete for tzinfo
classes that model internal DST changes.  If you say that the current
design cannot be tweaked to return 1:MM twice at negative DST changes,
then I'll respond to Guido's message asking for a better way with a
proposed change to make that possible.

>>> ... 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).

Okay, I got confused by your later paragraph about Guido living in UTC
time.  In this case, I'd say that you're doing a heuristic conversion
rather than an algebraic conversion -- and that's precisely what I'm
advocating.

>> 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.

Yup.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"There are three kinds of lies: Lies, Damn Lies, and Statistics."  --Disraeli