On Aug 13, 2005, at 11:53 PM, Stuart Bishop wrote:
Gary Poster wrote:
On a somewhat unrelated note, I noticed that dst() and tzname() were
not implemented per the standard library's spec

...snip explanation...

Ah, that makes a lot of sense. I had not understood all of that before you clarified it. Thanks.

Therefore I further propose that the zone attribute be exposed in docs
as a reliable attribute of the pytz timezones, and the key  through
which it is accessible from pytz.timezone.

Sure. I consider all of the attributes and methods not prefied with '_' as
reliable, and the zone attribute is already being testing in the
pytz.timezone docstring tests.


(The tzname() output isn't useful for
anything besides display anyway - its not unique. Australia has been know to have more than 6 different definitions of EST in a year, as it is used to mean both Eastern Standard Time and Eastern Summer Time and the multiple regions that use it will often choose different dates to do the transition.)


I've added lines accessing tz.zone to the main README.txt docs.

Great, thanks.

If that is a contract, BaseTZInfo's __reduce__ could instead

    return pytz.timezone, (self.zone)

, which might be more forward compatible (and not require DstTzInfo's
__init__ signature to change).

Something like this is preferable I think. However, it is more complicated. Because a DST aware tzinfo implementation for a timezone is actually a set of tzinfo instances, we need to ensure that the correct item in that set is

I think I've got this all setup correctly now - I've just checked it in to
my local dev branch and to:

If that looks fine to people, I'll put that out as the next pytz release and
merge that branch into the 3.1 and trunk branches.

Thanks for doing this! I'm no pickle expert, but the implementation jibed with what I do know, and the tests seemed very reasonable. +1 from me.

Thanks again

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to