Gary Poster wrote: > Hi Stuart. Hope all is well.
Just recovering from a work trip OS ;) > - document and test the contract that the timezones may be pickled, and > that loading the pickle returns the same original instance (i.e., it's > a singleton) Yup. > On a somewhat unrelated note, I noticed that dst() and tzname() were > not implemented per the standard library's spec; upon reflection, I > decided that this might be because the Olson database made this > difficult or impossible. Feel free to clarify or not; the point is > that I would like to use a name for the timezone, and the 'zone' > attribute seems to do enough what I want, even though it is not > daylight-savings aware. The dst() and tzname() methods are implemented differently to the example in the standard library in order to make the datetime instances using the tzinfo objects do unambiguous localtime arithmetic and generally make things actually work. It also allows a much richer timezone definition, such as provided by the Olson data, where the utcoffset, dstoffset, tznames etc. can change over time. The basis of the implementation is that we actually have a set of tzinfo instances for a timezone instead of just one. Each of them knows the static tzname, utcoffset and is_dst status for some time periods in the timezone. So for US/Eastern we have about 4 instances lumped together (EST, EDT, and some odd war time ones used between 1942 and 1945). Which actual tzinfo instance is used is selected when converting from UTC time. Because the tzinfo instance knows if it refers to a DST or non-DST time period in the timezone, we can unambiguously deal with those odd hours at DST transition times in the same way that other libraries can that store an is_dst flag in their datetime objects - effectively we have shuffled that bit of information Python elected not to store in the datetime instance into the timezone definition. > 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. > 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. -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
