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

Aahz aahz@pythoncraft.com
Thu, 2 Jan 2003 21:13:50 -0500


On Thu, Jan 02, 2003, Tim Peters wrote:
> [Aahz]
>>
>> I'm not sure I agree.  As I see it, "wall time" is for users.  On the
>> display side, I believe that users *expect* to see
>>
>> 1:59:57 am
>> 1:59:58 am
>> 1:59:59 am
>> 1:00:00 am
>> 1:00:01 am
>>
>> I therefore see no problem with the UTC->wall clock conversion.
> 
> That's defensible for some class of uses, although it may not be
> implementable.  The tzinfo classes here are arbitrary pieces of
> user-written Python code, and all astimezone() can do is (1) build
> objects and pass them to its methods, to see what they return; and,
> (2) make assumptions.  In particular, astimezone() has no knowledge of
> when DST begins or ends, or even of whether a tzinfo class believes
> there *is* such a thing as DST.
>
> In this case it can detect the unspellable hour, so I suppose it could
> add more code trying to infer what the local clock believes about it.

It sure sounds like you're saying that the DateTime module can't handle
timezone conversions at all.  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.

>> Presumably that only occurs as a result of user input, and when you
>> redisplay the input as a wall clock, it should be obvious to the user
>> if the wrong time zone was selected because the time will be an hour
>> (or whatever) off.  The only way this is a problem seems to be if you
>> want to do round-trip conversions purely programmatically.
> 
> If you view Guido's appointment calendar over the web, which he
> enters in US Eastern these days, and want it displayed in your local
> time, then (a) there's nothing roundtrip about it -- it's a one-way
> conversion; and (b) you'll have no idea whether some items are an hour
> off.  For a web-based group scheduling application, this isn't even a
> stretch.

I'm confused: are you saying that Guido's calendar doesn't get
internally converted to UTC?  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 -- that perhaps would be a suitable occasion for an
exception.

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.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

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