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

[Tim Peters]

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

> Going the other direction requires an explicit statement of which
> timezone you're in at the point of conversion (a real timezone,
> not a virtual one like "US Eastern").

As others have pointed out, C's struct tm tm_isdst flag serves this purpose
for "US Eastern", and such a flag *could* be added to datetimetz objects
too.  The practical reality appears to be that people want hybrid classes
like this, ill-defined or not.

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