Fixed #27327 -- Simplified time zone handling by requiring pytz.

8 files changed, 62 insertions, 80 deletions

diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index 137ab3e67f..39f49f10e6 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -117,9 +117,9 @@ Imports
 
       # try/except
       try:
-          import pytz
+          import yaml
       except ImportError:
-          pytz = None
+          yaml = None
 
       CONSTANT = 'foo'
 
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index d5fdb72561..bb77eced7d 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -232,7 +232,7 @@ dependencies:
 *  numpy_
 *  Pillow_
 *  PyYAML_
-*  pytz_
+*  pytz_ (required)
 *  setuptools_
 *  memcached_, plus a :ref:`supported Python binding <memcached>`
 *  mock_ (for Python 2)
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index f1c3864377..aa25cd2c0e 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -758,11 +758,11 @@ object. If it's ``None``, Django uses the :ref:`current time zone
     As a consequence, your database must be able to interpret the value of
     ``tzinfo.tzname(None)``. This translates into the following requirements:
 
-    - SQLite: install pytz_ — conversions are actually performed in Python.
+    - SQLite: no requirements. Conversions are performed in Python with pytz_
+      (installed when you install Django).
     - PostgreSQL: no requirements (see `Time Zones`_).
     - Oracle: no requirements (see `Choosing a Time Zone File`_).
-    - MySQL: install pytz_ and load the time zone tables with
-      `mysql_tzinfo_to_sql`_.
+    - MySQL: load the time zone tables with `mysql_tzinfo_to_sql`_.
 
     .. _pytz: http://pytz.sourceforge.net/
     .. _Time Zones: https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 223362c0f6..cf4da849c3 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -607,8 +607,6 @@ This allows interacting with third-party databases that store datetimes in
 local time rather than UTC. To avoid issues around DST changes, you shouldn't
 set this option for databases managed by Django.
 
-Setting this option requires installing pytz_.
-
 When :setting:`USE_TZ` is ``True`` and the database doesn't support time zones
 (e.g. SQLite, MySQL, Oracle), Django reads and writes datetimes in local time
 according to this option if it is set and in UTC if it isn't.
@@ -618,8 +616,6 @@ PostgreSQL), it is an error to set this option.
 
 When :setting:`USE_TZ` is ``False``, it is an error to set this option.
 
-.. _pytz: http://pytz.sourceforge.net/
-
 .. setting:: USER
 
 ``USER``
@@ -2478,8 +2474,8 @@ See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`.
 
 Default: ``'America/Chicago'``
 
-A string representing the time zone for this installation, or ``None``. See
-the `list of time zones`_.
+A string representing the time zone for this installation. See the `list of
+time zones`_.
 
 .. note::
     Since Django was first released with the :setting:`TIME_ZONE` set to
@@ -2496,22 +2492,15 @@ will store all datetimes. When :setting:`USE_TZ` is ``True``, this is the
 default time zone that Django will use to display datetimes in templates and
 to interpret datetimes entered in forms.
 
-Django sets the ``os.environ['TZ']`` variable to the time zone you specify in
-the :setting:`TIME_ZONE` setting. Thus, all your views and models will
+On Unix environments (where :func:`time.tzset` is implemented), Django sets the
+``os.environ['TZ']`` variable to the time zone you specify in the
+:setting:`TIME_ZONE` setting. Thus, all your views and models will
 automatically operate in this time zone. However, Django won't set the ``TZ``
-environment variable under the following conditions:
-
-* If you're using the manual configuration option as described in
-  :ref:`manually configuring settings
-  <settings-without-django-settings-module>`, or
-
-* If you specify ``TIME_ZONE = None``. This will cause Django to fall back to
-  using the system timezone. However, this is discouraged when :setting:`USE_TZ
-  = True <USE_TZ>`, because it makes conversions between local time and UTC
-  less reliable.
-
-If Django doesn't set the ``TZ`` environment variable, it's up to you
-to ensure your processes are running in the correct environment.
+environment variable if you're using the manual configuration option as
+described in :ref:`manually configuring settings
+<settings-without-django-settings-module>`. If Django doesn't set the ``TZ``
+environment variable, it's up to you to ensure your processes are running in
+the correct environment.
 
 .. note::
     Django cannot reliably use alternate time zones in a Windows environment.
diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt
index 45ffd80fc4..320f5db795 100644
--- a/docs/ref/utils.txt
+++ b/docs/ref/utils.txt
@@ -966,7 +966,7 @@ appropriate entities.
 
     Sets the :ref:`current time zone <default-current-time-zone>`. The
     ``timezone`` argument must be an instance of a :class:`~datetime.tzinfo`
-    subclass or, if pytz_ is available, a time zone name.
+    subclass or a time zone name.
 
 .. function:: deactivate()
 
@@ -1043,21 +1043,18 @@ appropriate entities.
     :class:`~datetime.datetime`. If ``timezone`` is set to ``None``, it
     defaults to the :ref:`current time zone <default-current-time-zone>`.
 
-    When pytz_ is installed, the exception ``pytz.AmbiguousTimeError``
-    will be raised if you try to make ``value`` aware during a DST transition
-    where the same time occurs twice (when reverting from DST). Setting
-    ``is_dst`` to ``True`` or ``False`` will avoid the exception by choosing if
-    the time is pre-transition or post-transition respectively.
+    The ``pytz.AmbiguousTimeError`` exception is raised if you try to make
+    ``value`` aware during a DST transition where the same time occurs twice
+    (when reverting from DST). Setting ``is_dst`` to ``True`` or ``False`` will
+    avoid the exception by choosing if the time is pre-transition or
+    post-transition respectively.
 
-    When pytz_ is installed, the exception ``pytz.NonExistentTimeError``
-    will be raised if you try to make ``value`` aware during a DST transition
-    such that the time never occurred (when entering into DST). Setting
-    ``is_dst`` to ``True`` or ``False`` will avoid the exception by moving the
-    hour backwards or forwards by 1 respectively. For example, ``is_dst=True``
-    would change a non-existent time of 2:30 to 1:30 and ``is_dst=False``
-    would change the time to 3:30.
-
-    ``is_dst`` has no effect when ``pytz`` is not installed.
+    The ``pytz.NonExistentTimeError`` exception is raised if you try to make
+    ``value`` aware during a DST transition such that the time never occurred
+    (when entering into DST). Setting ``is_dst`` to ``True`` or ``False`` will
+    avoid the exception by moving the hour backwards or forwards by 1
+    respectively. For example, ``is_dst=True`` would change a non-existent
+    time of 2:30 to 1:30 and ``is_dst=False`` would change the time to 3:30.
 
 .. function:: make_naive(value, timezone=None)
 
@@ -1066,8 +1063,6 @@ appropriate entities.
     aware :class:`~datetime.datetime`. If ``timezone`` is set to ``None``, it
     defaults to the :ref:`current time zone <default-current-time-zone>`.
 
-.. _pytz: http://pytz.sourceforge.net/
-
 ``django.utils.translation``
 ============================
 
diff --git a/docs/releases/1.11.txt b/docs/releases/1.11.txt
index 653de07caf..27f7481fa6 100644
--- a/docs/releases/1.11.txt
+++ b/docs/releases/1.11.txt
@@ -468,6 +468,27 @@ To prevent typos from passing silently,
 arguments are model fields. This should be backwards-incompatible only in the
 fact that it might expose a bug in your project.
 
+``pytz`` is a required dependency and support for ``settings.TIME_ZONE = None`` is removed
+------------------------------------------------------------------------------------------
+
+To simplify Django's timezone handling, ``pytz`` is now a required dependency.
+It's automatically installed along with Django.
+
+Support for ``settings.TIME_ZONE = None`` is removed as the behavior isn't
+commonly used and is questionably useful. If you want to automatically detect
+the timezone based on the system timezone, you can use `tzlocal
+<https://pypi.python.org/pypi/tzlocal>`_::
+
+    from tzlocal import get_localzone
+
+    TIME_ZONE = get_localzone().zone
+
+This works similar to ``settings.TIME_ZONE = None`` except that it also sets
+``os.environ['TZ']``. `Let us know
+<https://groups.google.com/d/topic/django-developers/OAV3FChfuPM/discussion>`__
+if there's a use case where you find you can't adapt your code to set a
+``TIME_ZONE``.
+
 Miscellaneous
 -------------
 
diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist
index 8218fe0219..13553bc5f1 100644
--- a/docs/spelling_wordlist
+++ b/docs/spelling_wordlist
@@ -622,7 +622,6 @@ Pygments
 pysqlite
 pythonic
 Pythonista
-pytz
 qs
 Québec
 queryset
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index a5848bf33e..ecabefb421 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -26,14 +26,12 @@ to this problem is to use UTC in the code and use local time only when
 interacting with end users.
 
 Time zone support is disabled by default. To enable it, set :setting:`USE_TZ =
-True <USE_TZ>` in your settings file. Installing pytz_ is highly recommended,
-but may not be mandatory depending on your particular database backend,
-operating system and time zone. If you encounter an exception querying dates
-or times, please try installing it before filing a bug. It's as simple as:
+True <USE_TZ>` in your settings file. Time zone support uses pytz_, which is
+installed when you install Django.
 
-.. code-block:: console
+.. versionchanged:: 1.11
 
-    $ pip install pytz
+    Older versions don't require ``pytz`` or install it automatically.
 
 .. note::
 
@@ -113,11 +111,8 @@ receives one, it attempts to make it aware by interpreting it in the
 :ref:`default time zone <default-current-time-zone>` and raises a warning.
 
 Unfortunately, during DST transitions, some datetimes don't exist or are
-ambiguous. In such situations, pytz_ raises an exception. Other
-:class:`~datetime.tzinfo` implementations, such as the local time zone used as
-a fallback when pytz_ isn't installed, may raise an exception or return
-inaccurate results. That's why you should always create aware datetime objects
-when time zone support is enabled.
+ambiguous. In such situations, pytz_ raises an exception. That's why you should
+always create aware datetime objects when time zone support is enabled.
 
 In practice, this is rarely an issue. Django gives you aware datetime objects
 in the models and forms, and most often, new datetime objects are created from
@@ -360,7 +355,7 @@ For example::
 Forces conversion of a single value to an arbitrary timezone.
 
 The argument must be an instance of a :class:`~datetime.tzinfo` subclass or a
-time zone name. If it is a time zone name, pytz_ is required.
+time zone name.
 
 For example::
 
@@ -405,9 +400,8 @@ Code
 ----
 
 The first step is to add :setting:`USE_TZ = True <USE_TZ>` to your settings
-file and install pytz_ (if possible). At this point, things should mostly
-work. If you create naive datetime objects in your code, Django makes them
-aware when necessary.
+file. At this point, things should mostly work. If you create naive datetime
+objects in your code, Django makes them aware when necessary.
 
 However, these conversions may fail around DST transitions, which means you
 aren't getting the full benefits of time zone support yet. Also, you're likely
@@ -523,22 +517,7 @@ Setup
    one year is 2011-02-28 or 2011-03-01, which depends on your business
    requirements.)
 
-3. **Should I install pytz?**
-
-   Yes. Django has a policy of not requiring external dependencies, and for
-   this reason pytz_ is optional. However, it's much safer to install it.
-
-   As soon as you activate time zone support, Django needs a definition of the
-   default time zone. When pytz is available, Django loads this definition
-   from the `tz database`_. This is the most accurate solution. Otherwise, it
-   relies on the difference between local time and UTC, as reported by the
-   operating system, to compute conversions. This is less reliable, especially
-   around DST transitions.
-
-   Furthermore, if you want to support users in more than one time zone, pytz
-   is the reference for time zone definitions.
-
-4. **How do I interact with a database that stores datetimes in local time?**
+3. **How do I interact with a database that stores datetimes in local time?**
 
    Set the :setting:`TIME_ZONE <DATABASE-TIME_ZONE>` option to the appropriate
    time zone for this database in the :setting:`DATABASES` setting.
@@ -653,8 +632,8 @@ Troubleshooting
        >>> local.date()
        datetime.date(2012, 3, 3)
 
-4. **I get an error** "``Are time zone definitions for your database and pytz
-   installed?``" **pytz is installed, so I guess the problem is my database?**
+4. **I get an error** "``Are time zone definitions for your database
+   installed?``"
 
    If you are using MySQL, see the :ref:`mysql-time-zone-definitions` section
    of the MySQL notes for instructions on loading time zone definitions.
@@ -700,8 +679,7 @@ Usage
        >>> timezone.localtime(timezone.now())
        datetime.datetime(2012, 3, 3, 20, 10, 53, 873365, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>)
 
-   In this example, pytz_ is installed and the current time zone is
-   ``"Europe/Paris"``.
+   In this example, the current time zone is ``"Europe/Paris"``.
 
 3. **How can I see all available time zones?**