ANN: pytz-2004b World timezone library

[David Bolen]

Tim Peters <tim.peters at gmail.com> writes:

> [Stuart Bishop]
> > ...
> > Although it would be a very minor and benign modification - just
> > need to call the localize method (if it exists) in the datetime
> > constructor and the normalize method (if it exists) before returning
> > the result of date arithmetic...
> 
> If you want to pursue it, submit a patch.  I expect, but don't know,
> that Guido would be opposed, because "naive time" is thought to be a
> feature in this module.  I suspect you think of it as a lazy
> compromise (or something of that nature), in which case there's a
> clash in design philosophies.

Wouldn't it be less a clash than simply a question as to whether the
interface between datetime and timezone objects is currently rich
enough to support functionality that does belong in the timezone?
That is, datetime should remain naive, but in order to permit an
associated timezone class to stay in sync in all cases, the timezone
object interface may need some notification of certain events, to
provide it the opportunity to compute needed adjustments. I'm not sure
that simply calling fixed interface points within an associated
timezone need imply datetime has timezone knowledge other than at the
most abstract level.

As it turns out I happen to be a user of just this sort of
functionality, because we've got a system where we need to schedule
something in a target time at a remote location, but the execution of
the task runs from a master site scheduled in a different timezone.
So we need to construct an appropriate datetime object in the target
timezone, and then convert it back into the master's timezone.  The
new localize() method in pytz handles the former, and the normalize()
method the latter, but it feels slightly off to be coding through the
timezone object, and re-normalizing at every stage, as opposed to just
associating a timezone object with the datatime instance and leaving
all timezone manipulations to that attached object.  I'm not looking
to have the datetime object itself understand the timezone, but it
does feel like it would be cleaner if the combination of the datetime
object and the associated timezone object could work together without
additional explicit support by the application.

-- David