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
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
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
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
mean both Eastern Standard Time and Eastern Summer Time and the
regions that use it will often choose different dates to do the
I've added lines accessing tz.zone to the main README.txt docs.
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
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
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
Zope3-dev mailing list