[Zope3-dev] mini-RFC: times and timezones

[Tim Peters]

[...]

[Gary Poster]
>>    * zope.i18n should grow a convenience method to convert dates from
>> utc to another timezone [6]

[Garrett Smith]
> It's surprising that Python's datetime module doesn't do this.

I'm more surprised that people think it doesn't <wink>.  For dt an
aware datetime.datetime, dt.astimezone(newtz) converts dt from dt's
time zone to time zone newtz.  If dt's time zone is UTC to begin with,
that's all it takes.  tzinfo subclasses also inherit an appropriate
fromutc(dt) method, which converts dt, viewed as being in UTC, to the
tzinfo subclass's time zone.  astimezone() calls fromutc() under the
covers, as explained in the docs.

This is all obscured by that while Python ships with an abstract
tzinfo base class, and a bunch of implementation code for time zone
conversion, it doesn't ship with any concrete tzinfo subclass -- not
even one for UTC.  An app has to supply its own, catering to whichever
detailed time zone rules it's willing to live with.

Backing up a bit:

>> - working with mixed Python timezone-aware and -naive datetimes is a
>> big pain (i.e., they don't work together well, and are not intended to
>> AFAIK).

That's correct.  Guido viewed them as different kinds of beasts, and
expected that most people would use the naive species most often.

A possibility I didn't see mentioned is to store aware datetimes but
with a UTC tzinfo subclass.  Then they're all stored in UTC, but play
nicely with other aware datetimes in other time zones.

A consideration I didn't see mentioned is that lots of work went into
ensuring that datetime objects have efficient pickle representations
(small size, and very fast to pickle and unpickle).  Of course this
works best for naive datetimes -- pickling an aware datetime drags in
all the machinery for pickling its instance of a tzinfo subclass too.