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