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

[Tim Peters]

[Aahz]
> Your love of mathematical precision sometimes gets in the way of
> clear answers to specific questions.  ;-)  (Yes, I saw the bit about
> ValueError earlier, but it was implied, not explicit.)

Given

     The current implementation of dt.astimezone(tz) raises
     ValueError if dt can't be expressed as a local time in tz.

following an explict example of that case, that's a meaning for "implied"
with which I was previously unacquainted <wink>.

> ...
> Uh, it sure looks to me like timetz defaults tzinfo to None, which I'd
> call "pure wall clock".

The docs call this "naive time", probably the same thing.

...

>> Under the agreement, Guido's calendar entries will display as 1:MM in
>> this case, if a programmer uses datetimetz.astimezone() to convert
>> them.  ...

> No, they shouldn't, assuming Guido's calendar entries are built out of
> timetz instances with tzinfo set to None.  Remember that Guido sticks
> in entries for 1pm in SF while he's still in DC.

I can't deduce from that whether the generation of Palm that builds its apps
with Python 2.3 will choose to create naive or aware times in its
appointment app.

> If you're going to handle this use case, there needs to be a way to
> spell it,

There are surely many ways to spell it, depending on all sorts of design
criteria that haven't been made explicit here.

> and someone trying to convert this to a timezone ought to get an
> exception.

You can't pass a time object or a timetz object (whether naive or aware
makes no difference) to astimezone(), if that's what you're worried about.
So, sure, you'll get a TypeError exception if you try.