summaryrefslogtreecommitdiff
path: root/pytz.egg-info/PKG-INFO
diff options
context:
space:
mode:
Diffstat (limited to 'pytz.egg-info/PKG-INFO')
-rw-r--r--pytz.egg-info/PKG-INFO595
1 files changed, 595 insertions, 0 deletions
diff --git a/pytz.egg-info/PKG-INFO b/pytz.egg-info/PKG-INFO
new file mode 100644
index 0000000..5577abd
--- /dev/null
+++ b/pytz.egg-info/PKG-INFO
@@ -0,0 +1,595 @@
+Metadata-Version: 1.1
+Name: pytz
+Version: 2014.10
+Summary: World timezone definitions, modern and historical
+Home-page: http://pythonhosted.org/pytz
+Author: Stuart Bishop
+Author-email: stuart@stuartbishop.net
+License: MIT
+Download-URL: http://pypi.python.org/pypi/pytz
+Description: pytz - World Timezone Definitions for Python
+ ============================================
+
+ :Author: Stuart Bishop <stuart@stuartbishop.net>
+
+ Introduction
+ ~~~~~~~~~~~~
+
+ pytz brings the Olson tz database into Python. This library allows
+ accurate and cross platform timezone calculations using Python 2.4
+ or higher. It also solves the issue of ambiguous times at the end
+ of daylight saving time, which you can read more about in the Python
+ Library Reference (``datetime.tzinfo``).
+
+ Almost all of the Olson timezones are supported.
+
+ .. note::
+
+ This library differs from the documented Python API for
+ tzinfo implementations; if you want to create local wallclock
+ times you need to use the ``localize()`` method documented in this
+ document. In addition, if you perform date arithmetic on local
+ times that cross DST boundaries, the result 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). A
+ ``normalize()`` method is provided to correct this. Unfortunately these
+ issues cannot be resolved without modifying the Python datetime
+ implementation (see PEP-431).
+
+
+ Installation
+ ~~~~~~~~~~~~
+
+ This package can either be installed from a .egg file using setuptools,
+ or from the tarball using the standard Python distutils.
+
+ If you are installing from a tarball, run the following command as an
+ administrative user::
+
+ python setup.py install
+
+ If you are installing using setuptools, you don't even need to download
+ anything as the latest version will be downloaded for you
+ from the Python package index::
+
+ easy_install --upgrade pytz
+
+ If you already have the .egg file, you can use that too::
+
+ easy_install pytz-2008g-py2.6.egg
+
+
+ Example & Usage
+ ~~~~~~~~~~~~~~~
+
+ Localized times and date arithmetic
+ -----------------------------------
+
+ >>> from datetime import datetime, timedelta
+ >>> from pytz import timezone
+ >>> import pytz
+ >>> utc = pytz.utc
+ >>> utc.zone
+ 'UTC'
+ >>> eastern = timezone('US/Eastern')
+ >>> eastern.zone
+ 'US/Eastern'
+ >>> amsterdam = timezone('Europe/Amsterdam')
+ >>> fmt = '%Y-%m-%d %H:%M:%S %Z%z'
+
+ This library only supports two ways of building a localized time. The
+ first is to use the ``localize()`` method provided by the pytz library.
+ This is used to localize a naive datetime (datetime with no timezone
+ information):
+
+ >>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0))
+ >>> print(loc_dt.strftime(fmt))
+ 2002-10-27 06:00:00 EST-0500
+
+ The second way of building a localized time is by converting an existing
+ localized time using the standard ``astimezone()`` method:
+
+ >>> ams_dt = loc_dt.astimezone(amsterdam)
+ >>> ams_dt.strftime(fmt)
+ '2002-10-27 12:00:00 CET+0100'
+
+ Unfortunately using the tzinfo argument of the standard datetime
+ constructors ''does not work'' with pytz for many timezones.
+
+ >>> datetime(2002, 10, 27, 12, 0, 0, tzinfo=amsterdam).strftime(fmt)
+ '2002-10-27 12:00:00 LMT+0020'
+
+ It is safe for timezones without daylight saving transitions though, such
+ as UTC:
+
+ >>> datetime(2002, 10, 27, 12, 0, 0, tzinfo=pytz.utc).strftime(fmt)
+ '2002-10-27 12:00:00 UTC+0000'
+
+ The preferred way of dealing with times is to always work in UTC,
+ converting to localtime only when generating output to be read
+ by humans.
+
+ >>> utc_dt = datetime(2002, 10, 27, 6, 0, 0, tzinfo=utc)
+ >>> loc_dt = utc_dt.astimezone(eastern)
+ >>> loc_dt.strftime(fmt)
+ '2002-10-27 01:00:00 EST-0500'
+
+ This library also allows you to do date arithmetic using local
+ times, although it is more complicated than working in UTC as you
+ need to use the ``normalize()`` method to handle daylight saving time
+ and other timezone transitions. In this example, ``loc_dt`` is set
+ to the instant when daylight saving time ends in the US/Eastern
+ timezone.
+
+ >>> before = loc_dt - timedelta(minutes=10)
+ >>> before.strftime(fmt)
+ '2002-10-27 00:50:00 EST-0500'
+ >>> eastern.normalize(before).strftime(fmt)
+ '2002-10-27 01:50:00 EDT-0400'
+ >>> after = eastern.normalize(before + timedelta(minutes=20))
+ >>> after.strftime(fmt)
+ '2002-10-27 01:10:00 EST-0500'
+
+ Creating local times is also tricky, and the reason why working with
+ local times is not recommended. Unfortunately, you cannot just pass
+ a ``tzinfo`` argument when constructing a datetime (see the next
+ section for more details)
+
+ >>> dt = datetime(2002, 10, 27, 1, 30, 0)
+ >>> dt1 = eastern.localize(dt, is_dst=True)
+ >>> dt1.strftime(fmt)
+ '2002-10-27 01:30:00 EDT-0400'
+ >>> dt2 = eastern.localize(dt, is_dst=False)
+ >>> dt2.strftime(fmt)
+ '2002-10-27 01:30:00 EST-0500'
+
+ Converting between timezones also needs special attention. We also need
+ to use the ``normalize()`` method to ensure the conversion is correct.
+
+ >>> utc_dt = utc.localize(datetime.utcfromtimestamp(1143408899))
+ >>> utc_dt.strftime(fmt)
+ '2006-03-26 21:34:59 UTC+0000'
+ >>> au_tz = timezone('Australia/Sydney')
+ >>> au_dt = au_tz.normalize(utc_dt.astimezone(au_tz))
+ >>> au_dt.strftime(fmt)
+ '2006-03-27 08:34:59 AEDT+1100'
+ >>> utc_dt2 = utc.normalize(au_dt.astimezone(utc))
+ >>> utc_dt2.strftime(fmt)
+ '2006-03-26 21:34:59 UTC+0000'
+
+ You can take shortcuts when dealing with the UTC side of timezone
+ conversions. ``normalize()`` and ``localize()`` are not really
+ necessary when there are no daylight saving time transitions to
+ deal with.
+
+ >>> utc_dt = datetime.utcfromtimestamp(1143408899).replace(tzinfo=utc)
+ >>> utc_dt.strftime(fmt)
+ '2006-03-26 21:34:59 UTC+0000'
+ >>> au_tz = timezone('Australia/Sydney')
+ >>> au_dt = au_tz.normalize(utc_dt.astimezone(au_tz))
+ >>> au_dt.strftime(fmt)
+ '2006-03-27 08:34:59 AEDT+1100'
+ >>> utc_dt2 = au_dt.astimezone(utc)
+ >>> utc_dt2.strftime(fmt)
+ '2006-03-26 21:34:59 UTC+0000'
+
+
+ ``tzinfo`` API
+ --------------
+
+ The ``tzinfo`` instances returned by the ``timezone()`` function have
+ been extended to cope with ambiguous times by adding an ``is_dst``
+ parameter to the ``utcoffset()``, ``dst()`` && ``tzname()`` methods.
+
+ >>> tz = timezone('America/St_Johns')
+
+ >>> normal = datetime(2009, 9, 1)
+ >>> ambiguous = datetime(2009, 10, 31, 23, 30)
+
+ The ``is_dst`` parameter is ignored for most timestamps. It is only used
+ during DST transition ambiguous periods to resulve that ambiguity.
+
+ >>> tz.utcoffset(normal, is_dst=True)
+ datetime.timedelta(-1, 77400)
+ >>> tz.dst(normal, is_dst=True)
+ datetime.timedelta(0, 3600)
+ >>> tz.tzname(normal, is_dst=True)
+ 'NDT'
+
+ >>> tz.utcoffset(ambiguous, is_dst=True)
+ datetime.timedelta(-1, 77400)
+ >>> tz.dst(ambiguous, is_dst=True)
+ datetime.timedelta(0, 3600)
+ >>> tz.tzname(ambiguous, is_dst=True)
+ 'NDT'
+
+ >>> tz.utcoffset(normal, is_dst=False)
+ datetime.timedelta(-1, 77400)
+ >>> tz.dst(normal, is_dst=False)
+ datetime.timedelta(0, 3600)
+ >>> tz.tzname(normal, is_dst=False)
+ 'NDT'
+
+ >>> tz.utcoffset(ambiguous, is_dst=False)
+ datetime.timedelta(-1, 73800)
+ >>> tz.dst(ambiguous, is_dst=False)
+ datetime.timedelta(0)
+ >>> tz.tzname(ambiguous, is_dst=False)
+ 'NST'
+
+ If ``is_dst`` is not specified, ambiguous timestamps will raise
+ an ``pytz.exceptions.AmbiguousTimeError`` exception.
+
+ >>> tz.utcoffset(normal)
+ datetime.timedelta(-1, 77400)
+ >>> tz.dst(normal)
+ datetime.timedelta(0, 3600)
+ >>> tz.tzname(normal)
+ 'NDT'
+
+ >>> import pytz.exceptions
+ >>> try:
+ ... tz.utcoffset(ambiguous)
+ ... except pytz.exceptions.AmbiguousTimeError:
+ ... print('pytz.exceptions.AmbiguousTimeError: %s' % ambiguous)
+ pytz.exceptions.AmbiguousTimeError: 2009-10-31 23:30:00
+ >>> try:
+ ... tz.dst(ambiguous)
+ ... except pytz.exceptions.AmbiguousTimeError:
+ ... print('pytz.exceptions.AmbiguousTimeError: %s' % ambiguous)
+ pytz.exceptions.AmbiguousTimeError: 2009-10-31 23:30:00
+ >>> try:
+ ... tz.tzname(ambiguous)
+ ... except pytz.exceptions.AmbiguousTimeError:
+ ... print('pytz.exceptions.AmbiguousTimeError: %s' % ambiguous)
+ pytz.exceptions.AmbiguousTimeError: 2009-10-31 23:30:00
+
+
+ Problems with Localtime
+ ~~~~~~~~~~~~~~~~~~~~~~~
+
+ The major problem we have to deal with is that certain datetimes
+ may occur twice in a year. For example, in the US/Eastern timezone
+ on the last Sunday morning in October, the following sequence
+ happens:
+
+ - 01:00 EDT occurs
+ - 1 hour later, instead of 2:00am the clock is turned back 1 hour
+ and 01:00 happens again (this time 01:00 EST)
+
+ In fact, every instant between 01:00 and 02:00 occurs twice. This means
+ that if you try and create a time in the 'US/Eastern' timezone
+ the standard datetime syntax, there is no way to specify if you meant
+ before of after the end-of-daylight-saving-time transition. Using the
+ pytz custom syntax, the best you can do is make an educated guess:
+
+ >>> loc_dt = eastern.localize(datetime(2002, 10, 27, 1, 30, 00))
+ >>> loc_dt.strftime(fmt)
+ '2002-10-27 01:30:00 EST-0500'
+
+ As you can see, the system has chosen one for you and there is a 50%
+ chance of it being out by one hour. For some applications, this does
+ not matter. However, if you are trying to schedule meetings with people
+ in different timezones or analyze log files it is not acceptable.
+
+ The best and simplest solution is to stick with using UTC. The pytz
+ package encourages using UTC for internal timezone representation by
+ including a special UTC implementation based on the standard Python
+ reference implementation in the Python documentation.
+
+ The UTC timezone unpickles to be the same instance, and pickles to a
+ smaller size than other pytz tzinfo instances. The UTC implementation
+ can be obtained as pytz.utc, pytz.UTC, or pytz.timezone('UTC').
+
+ >>> import pickle, pytz
+ >>> dt = datetime(2005, 3, 1, 14, 13, 21, tzinfo=utc)
+ >>> naive = dt.replace(tzinfo=None)
+ >>> p = pickle.dumps(dt, 1)
+ >>> naive_p = pickle.dumps(naive, 1)
+ >>> len(p) - len(naive_p)
+ 17
+ >>> new = pickle.loads(p)
+ >>> new == dt
+ True
+ >>> new is dt
+ False
+ >>> new.tzinfo is dt.tzinfo
+ True
+ >>> pytz.utc is pytz.UTC is pytz.timezone('UTC')
+ True
+
+ Note that some other timezones are commonly thought of as the same (GMT,
+ Greenwich, Universal, etc.). The definition of UTC is distinct from these
+ other timezones, and they are not equivalent. For this reason, they will
+ not compare the same in Python.
+
+ >>> utc == pytz.timezone('GMT')
+ False
+
+ See the section `What is UTC`_, below.
+
+ If you insist on working with local times, this library provides a
+ facility for constructing them unambiguously:
+
+ >>> loc_dt = datetime(2002, 10, 27, 1, 30, 00)
+ >>> est_dt = eastern.localize(loc_dt, is_dst=True)
+ >>> edt_dt = eastern.localize(loc_dt, is_dst=False)
+ >>> print(est_dt.strftime(fmt) + ' / ' + edt_dt.strftime(fmt))
+ 2002-10-27 01:30:00 EDT-0400 / 2002-10-27 01:30:00 EST-0500
+
+ If you pass None as the is_dst flag to localize(), pytz will refuse to
+ guess and raise exceptions if you try to build ambiguous or non-existent
+ times.
+
+ For example, 1:30am on 27th Oct 2002 happened twice in the US/Eastern
+ timezone when the clocks where put back at the end of Daylight Saving
+ Time:
+
+ >>> dt = datetime(2002, 10, 27, 1, 30, 00)
+ >>> try:
+ ... eastern.localize(dt, is_dst=None)
+ ... except pytz.exceptions.AmbiguousTimeError:
+ ... print('pytz.exceptions.AmbiguousTimeError: %s' % dt)
+ pytz.exceptions.AmbiguousTimeError: 2002-10-27 01:30:00
+
+ Similarly, 2:30am on 7th April 2002 never happened at all in the
+ US/Eastern timezone, as the clocks where put forward at 2:00am skipping
+ the entire hour:
+
+ >>> dt = datetime(2002, 4, 7, 2, 30, 00)
+ >>> try:
+ ... eastern.localize(dt, is_dst=None)
+ ... except pytz.exceptions.NonExistentTimeError:
+ ... print('pytz.exceptions.NonExistentTimeError: %s' % dt)
+ pytz.exceptions.NonExistentTimeError: 2002-04-07 02:30:00
+
+ Both of these exceptions share a common base class to make error handling
+ easier:
+
+ >>> isinstance(pytz.AmbiguousTimeError(), pytz.InvalidTimeError)
+ True
+ >>> isinstance(pytz.NonExistentTimeError(), pytz.InvalidTimeError)
+ True
+
+
+ A special case is where countries change their timezone definitions
+ with no daylight savings time switch. For example, in 1915 Warsaw
+ switched from Warsaw time to Central European time with no daylight savings
+ transition. So at the stroke of midnight on August 5th 1915 the clocks
+ were wound back 24 minutes creating an ambiguous time period that cannot
+ be specified without referring to the timezone abbreviation or the
+ actual UTC offset. In this case midnight happened twice, neither time
+ during a daylight saving time period. pytz handles this transition by
+ treating the ambiguous period before the switch as daylight savings
+ time, and the ambiguous period after as standard time.
+
+
+ >>> warsaw = pytz.timezone('Europe/Warsaw')
+ >>> amb_dt1 = warsaw.localize(datetime(1915, 8, 4, 23, 59, 59), is_dst=True)
+ >>> amb_dt1.strftime(fmt)
+ '1915-08-04 23:59:59 WMT+0124'
+ >>> amb_dt2 = warsaw.localize(datetime(1915, 8, 4, 23, 59, 59), is_dst=False)
+ >>> amb_dt2.strftime(fmt)
+ '1915-08-04 23:59:59 CET+0100'
+ >>> switch_dt = warsaw.localize(datetime(1915, 8, 5, 00, 00, 00), is_dst=False)
+ >>> switch_dt.strftime(fmt)
+ '1915-08-05 00:00:00 CET+0100'
+ >>> str(switch_dt - amb_dt1)
+ '0:24:01'
+ >>> str(switch_dt - amb_dt2)
+ '0:00:01'
+
+ The best way of creating a time during an ambiguous time period is
+ by converting from another timezone such as UTC:
+
+ >>> utc_dt = datetime(1915, 8, 4, 22, 36, tzinfo=pytz.utc)
+ >>> utc_dt.astimezone(warsaw).strftime(fmt)
+ '1915-08-04 23:36:00 CET+0100'
+
+ The standard Python way of handling all these ambiguities is not to
+ handle them, such as demonstrated in this example using the US/Eastern
+ timezone definition from the Python documentation (Note that this
+ implementation only works for dates between 1987 and 2006 - it is
+ included for tests only!):
+
+ >>> from pytz.reference import Eastern # pytz.reference only for tests
+ >>> dt = datetime(2002, 10, 27, 0, 30, tzinfo=Eastern)
+ >>> str(dt)
+ '2002-10-27 00:30:00-04:00'
+ >>> str(dt + timedelta(hours=1))
+ '2002-10-27 01:30:00-05:00'
+ >>> str(dt + timedelta(hours=2))
+ '2002-10-27 02:30:00-05:00'
+ >>> str(dt + timedelta(hours=3))
+ '2002-10-27 03:30:00-05:00'
+
+ Notice the first two results? At first glance you might think they are
+ correct, but taking the UTC offset into account you find that they are
+ actually two hours appart instead of the 1 hour we asked for.
+
+ >>> from pytz.reference import UTC # pytz.reference only for tests
+ >>> str(dt.astimezone(UTC))
+ '2002-10-27 04:30:00+00:00'
+ >>> str((dt + timedelta(hours=1)).astimezone(UTC))
+ '2002-10-27 06:30:00+00:00'
+
+
+ Country Information
+ ~~~~~~~~~~~~~~~~~~~
+
+ A mechanism is provided to access the timezones commonly in use
+ for a particular country, looked up using the ISO 3166 country code.
+ It returns a list of strings that can be used to retrieve the relevant
+ tzinfo instance using ``pytz.timezone()``:
+
+ >>> print(' '.join(pytz.country_timezones['nz']))
+ Pacific/Auckland Pacific/Chatham
+
+ The Olson database comes with a ISO 3166 country code to English country
+ name mapping that pytz exposes as a dictionary:
+
+ >>> print(pytz.country_names['nz'])
+ New Zealand
+
+
+ What is UTC
+ ~~~~~~~~~~~
+
+ 'UTC' is `Coordinated Universal Time`_. It is a successor to, but distinct
+ from, Greenwich Mean Time (GMT) and the various definitions of Universal
+ Time. UTC is now the worldwide standard for regulating clocks and time
+ measurement.
+
+ All other timezones are defined relative to UTC, and include offsets like
+ UTC+0800 - hours to add or subtract from UTC to derive the local time. No
+ daylight saving time occurs in UTC, making it a useful timezone to perform
+ date arithmetic without worrying about the confusion and ambiguities caused
+ by daylight saving time transitions, your country changing its timezone, or
+ mobile computers that roam through multiple timezones.
+
+ .. _Coordinated Universal Time: https://en.wikipedia.org/wiki/Coordinated_Universal_Time
+
+
+ Helpers
+ ~~~~~~~
+
+ There are two lists of timezones provided.
+
+ ``all_timezones`` is the exhaustive list of the timezone names that can
+ be used.
+
+ >>> from pytz import all_timezones
+ >>> len(all_timezones) >= 500
+ True
+ >>> 'Etc/Greenwich' in all_timezones
+ True
+
+ ``common_timezones`` is a list of useful, current timezones. It doesn't
+ contain deprecated zones or historical zones, except for a few I've
+ deemed in common usage, such as US/Eastern (open a bug report if you
+ think other timezones are deserving of being included here). It is also
+ a sequence of strings.
+
+ >>> from pytz import common_timezones
+ >>> len(common_timezones) < len(all_timezones)
+ True
+ >>> 'Etc/Greenwich' in common_timezones
+ False
+ >>> 'Australia/Melbourne' in common_timezones
+ True
+ >>> 'US/Eastern' in common_timezones
+ True
+ >>> 'Canada/Eastern' in common_timezones
+ True
+ >>> 'US/Pacific-New' in all_timezones
+ True
+ >>> 'US/Pacific-New' in common_timezones
+ False
+
+ Both ``common_timezones`` and ``all_timezones`` are alphabetically
+ sorted:
+
+ >>> common_timezones_dupe = common_timezones[:]
+ >>> common_timezones_dupe.sort()
+ >>> common_timezones == common_timezones_dupe
+ True
+ >>> all_timezones_dupe = all_timezones[:]
+ >>> all_timezones_dupe.sort()
+ >>> all_timezones == all_timezones_dupe
+ True
+
+ ``all_timezones`` and ``common_timezones`` are also available as sets.
+
+ >>> from pytz import all_timezones_set, common_timezones_set
+ >>> 'US/Eastern' in all_timezones_set
+ True
+ >>> 'US/Eastern' in common_timezones_set
+ True
+ >>> 'Australia/Victoria' in common_timezones_set
+ False
+
+ You can also retrieve lists of timezones used by particular countries
+ using the ``country_timezones()`` function. It requires an ISO-3166
+ two letter country code.
+
+ >>> from pytz import country_timezones
+ >>> print(' '.join(country_timezones('ch')))
+ Europe/Zurich
+ >>> print(' '.join(country_timezones('CH')))
+ Europe/Zurich
+
+
+ License
+ ~~~~~~~
+
+ MIT license.
+
+ This code is also available as part of Zope 3 under the Zope Public
+ License, Version 2.1 (ZPL).
+
+ I'm happy to relicense this code if necessary for inclusion in other
+ open source projects.
+
+
+ Latest Versions
+ ~~~~~~~~~~~~~~~
+
+ This package will be updated after releases of the Olson timezone
+ database. The latest version can be downloaded from the `Python Package
+ Index <http://pypi.python.org/pypi/pytz/>`_. The code that is used
+ to generate this distribution is hosted on launchpad.net and available
+ using the `Bazaar version control system <http://bazaar-vcs.org>`_
+ using::
+
+ bzr branch lp:pytz
+
+ Announcements of new releases are made on
+ `Launchpad <https://launchpad.net/pytz>`_, and the
+ `Atom feed <http://feeds.launchpad.net/pytz/announcements.atom>`_
+ hosted there.
+
+
+ Bugs, Feature Requests & Patches
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Bugs can be reported using `Launchpad <https://bugs.launchpad.net/pytz>`_.
+
+
+ Issues & Limitations
+ ~~~~~~~~~~~~~~~~~~~~
+
+ - Offsets from UTC are rounded to the nearest whole minute, so timezones
+ such as Europe/Amsterdam pre 1937 will be up to 30 seconds out. This
+ is a limitation of the Python datetime library.
+
+ - If you think a timezone definition is incorrect, I probably can't fix
+ it. pytz is a direct translation of the Olson timezone database, and
+ changes to the timezone definitions need to be made to this source.
+ If you find errors they should be reported to the time zone mailing
+ list, linked from http://www.iana.org/time-zones.
+
+
+ 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>
+
+
+
+Keywords: timezone,tzinfo,datetime,olson,time
+Platform: Independant
+Classifier: Development Status :: 6 - Mature
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Natural Language :: English
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Software Development :: Libraries :: Python Modules