[Zope3-dev] Re: More pytz pickling; 'zone' attribute

[Gary Poster]

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.

Cool.

> (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
> returned.
>
> I think I've got this all setup correctly now - I've just checked  
> it in to
> my local dev branch and to:
> svn+ssh://svn.zope.org/repos/main/Zope3/branches/stub-pytzpickle
>
> 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

Gary