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
