summaryrefslogtreecommitdiff
path: root/docs/ref
diff options
context:
space:
mode:
authorTim Graham <timograham@gmail.com>2016-10-07 21:06:49 -0400
committerTim Graham <timograham@gmail.com>2016-10-27 08:53:20 -0400
commit414ad25b090a63eaaf297b1164c8f7d814a710a2 (patch)
treee3d0e6fdffee0793baad41a339c2d63db742c33a /docs/ref
parentd84ffcc22b2a0dbc0a44a67d56da7e3647e2f87a (diff)
Fixed #27327 -- Simplified time zone handling by requiring pytz.
Diffstat (limited to 'docs/ref')
-rw-r--r--docs/ref/models/querysets.txt6
-rw-r--r--docs/ref/settings.txt31
-rw-r--r--docs/ref/utils.txt29
3 files changed, 25 insertions, 41 deletions
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``
============================