-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://sourceforge.net/projects/pytz/ pytz is a transformation of the public domain Olsen timezone database into pure Python code. This library allows accurate and cross platform timezone calculations using Python 2.3 or higher. This implementation solves the issue of ambiguous times at the end of daylight savings, which you can read more about in the Python Library Reference (datetime.tzinfo). The only remaining inaccuracy is that datetime.strftime only reports the UTC offset to the nearest minute (This is probably a feature - you have to draw a line somewhere). 536 of the Olsen timezones are supported. The missing few are for Riyadh Solar Time in 1987, 1988 and 1989. As Saudi Arabia gave up trying to cope with their timezone definition, I see no reason to complicate my code further to cope with them. (I understand the intention was to set sunset to 0:00 local time, the start of the Islamic day. In the best case caused the DST offset to change daily and worst case caused the DST offset to change each instant depending on how you interpreted the ruling.) Note that if you perform date arithmetic on local times that cross DST boundaries, the results may be in an incorrect timezone (ie. subtract 1 minute from 2002-10-27 1:00 EST and you get 2002-10-27 0:59 EST instead of the correct 2002-10-27 1:59 EDT). This cannot be resolved without modifying the Python datetime implementation. However, these tzinfo classes provide a normalize() method which allows you to correct these values. Installation ============ This is a standard Python distutils distribution. To install the package, run the following command as an administrative user:: python setup.py install License ======= BSD style license. I'm more than happy to relicense this code for inclusion in other open source projects. Example & Usage =============== >>> from datetime import datetime, timedelta >>> from pytz import timezone >>> utc = timezone('UTC') >>> eastern = timezone('US/Eastern') >>> utc_dt = datetime(2002, 10, 27, 6, 0, 0, tzinfo=utc) >>> loc_dt = utc_dt.astimezone(eastern) >>> fmt = '%Y-%m-%d %H:%M:%S %Z (%z)' >>> loc_dt.strftime(fmt) '2002-10-27 01:00:00 EST (-0500)' >>> (loc_dt - timedelta(minutes=10)).strftime(fmt) '2002-10-27 00:50:00 EST (-0500)' >>> eastern.normalize(loc_dt - timedelta(minutes=10)).strftime(fmt) '2002-10-27 01:50:00 EDT (-0400)' >>> (loc_dt + timedelta(minutes=10)).strftime(fmt) '2002-10-27 01:10:00 EST (-0500)' Latest Versions =============== This module will be updated after releases of the Olsen timezone database. The latest version can be downloaded from sourceforge_. .. _sourceforge: http://sourceforge.net/projects/pytz/ Further Reading =============== More info than you want to know about timezones:: http://www.twinsun.com/tz/tz-link.htm Contact ======= Stuart Bishop <stuart@stuartbishop.net> - -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA2bWTAfqZj7rGN0oRAjF0AJwMEwGDgODszthhjETIAUqXFSOxfACfbkeH hJh13lBU3ge5UYtes0niQu8= =sEx7 -----END PGP SIGNATURE-----
Stuart Bishop <zen@shangri-la.dropbear.id.au> writes:
.. _sourceforge: http://sourceforge.net/projects/pytz/
Thanks. I'd like to mention this in tz-links.htm but I'm at a bit of a loss as to how to characterize it. Is it a copy of the tz database, or a tz compiler, or some combination of the two? Clearly your approach differs from that of the Python time zones project <http://s.keim.free.fr/tz/doc.html> but I can't easily put my finger on the difference. For example, pytz-2004a.tar.bz2 contains a lot of files saying "Generated from the Olson timezone database" but I don't see a copy of the program used to generate those files. Surely this is an important part of the project. Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/06/2004, at 5:54 PM, Paul Eggert wrote:
Stuart Bishop <zen@shangri-la.dropbear.id.au> writes:
.. _sourceforge: http://sourceforge.net/projects/pytz/
Thanks. I'd like to mention this in tz-links.htm but I'm at a bit of a loss as to how to characterize it. Is it a copy of the tz database, or a tz compiler, or some combination of the two? Clearly your approach differs from that of the Python time zones project <http://s.keim.free.fr/tz/doc.html> but I can't easily put my finger on the difference.
Its a transformation of the database into Python source code :-) How about "A Python timezone implementation with embedded database". The major difference is that my implementation relies on no external data files (they are embedded in the generated source code), and can thus be run on any platform that supports Python 2.3 (including .net and Java running in a web browser when those ports are brought up to that standard). The tradeoff is space. I don't know which technique is faster to load. I made sure that no data is stored in instances of the tzinfo classes (just in the class definition itself). This is important when they are stored persistently, such as in Zope's object database, so that objects instantiated in previous releases will have the current timezone data. I do not know if this is the case with Sebastien Keim's implementation, although it would be possible to make it behave like this if it doesn't. I also worked out how to avoid the ambiguous end-of-DST transition times designed into the Python datetime library, although there is nothing stopping anyone else using this technique if they want. For the curious who want to know why I just didn't submit a patch to the existing project, it was because this code was almost complete around May 2003. I just never got around to fixing the DST transition 'feature' or getting it release ready until recently due to work commitments.
For example, pytz-2004a.tar.bz2 contains a lot of files saying "Generated from the Olson timezone database" but I don't see a copy of the program used to generate those files. Surely this is an important part of the project.
This code in the CVS repository at sourceforge is used to generate the distribution files and the full testsuite. Details: http://sourceforge.net/cvs/?group_id=79122 Browse: http://cvs.sourceforge.net/viewcvs.py/pytz/pytz/ I'll make a note of this in the README for the next release. - -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA2x8RAfqZj7rGN0oRAk/UAJsH4xJuKaYWdYCxInNfoMKarBRUzQCgmUOY uRrehtGuKQZeQhz6UobY4VQ= =oqyz -----END PGP SIGNATURE-----
participants (2)
-
Paul Eggert -
Stuart Bishop