diff options
| -rw-r--r-- | docs/releases/4.0.txt | 40 | ||||
| -rw-r--r-- | docs/topics/i18n/timezones.txt | 4 |
2 files changed, 23 insertions, 21 deletions
diff --git a/docs/releases/4.0.txt b/docs/releases/4.0.txt index be9f198e14..57d3e7ef03 100644 --- a/docs/releases/4.0.txt +++ b/docs/releases/4.0.txt @@ -43,31 +43,29 @@ deprecated and will be removed in Django 5.0. ``backports.zoneinfo`` package is automatically installed alongside Django if you are using Python 3.8. -To the extent that you are always operating on aware datetimes with UTC, then -the move to ``zoneinfo`` should be largely transparent. +The move to ``zoneinfo`` should be largely transparent. Selection of current +timezone, conversion of datetime instances to the current timezone in forms and +templates, as well as operations on aware datetimes in UTC are unaffected. -However, if you are you are working with non-UTC time zones, you will need to -audit your code, since ``pytz`` and ``zoneinfo`` are not entirely equivalent: +However, if you are you are working with non-UTC time zones, and particularly +using the ``pytz`` ``normalize()`` and ``localize()`` APIs, possibly with the +:setting:`DATABASE-TIME_ZONE` setting, you will need to audit your code, since +``pytz`` and ``zoneinfo`` are not entirely equivalent. -* The transitional :setting:`USE_DEPRECATED_PYTZ` setting is provided to - continue using ``pytz`` during the 4.x release cycle. This setting will be - removed in Django 5.0. +To allow time for such an audit, the transitional +:setting:`USE_DEPRECATED_PYTZ` setting allows continued use of ``pytz`` during +the 4.x release cycle. This setting will be removed in Django 5.0. -* Usages of :func:`django.utils.timezone.activate`, - :func:`django.utils.timezone.override`, or the :setting:`DATABASE-TIME_ZONE` - setting, as well as calls to the ``pytz`` ``normalize()`` or ``localize()`` - functions are candidate locations for review. +In addition, a `pytz_deprecation_shim`_ package is provided by the ``zoneinfo`` +author to assist with the migration from ``pytz``. This package gives shims to +help you safely remove ``pytz``, and has a detailed `migration guide`_ showing +how to move to the new ``zoneinfo`` APIs. -* The ``is_dst`` argument to :func:`django.utils.timezone.make_aware`, and - functions that proxy to it, is also deprecated, since it has no effect for - ``zoneinfo`` time zones. - -The Python Core Team maintain a `pytz_deprecation_shim`_ package to assist the -migration to ``zoneinfo``. Use of this package plus the -:setting:`USE_DEPRECATED_PYTZ` transitional setting is recommended if you need -a gradual update path. +Using `pytz_deprecation_shim`_ and the :setting:`USE_DEPRECATED_PYTZ` +transitional setting is recommended if you need a gradual update path. .. _pytz_deprecation_shim: https://pytz-deprecation-shim.readthedocs.io/en/latest/index.html +.. _migration guide: https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html Functional unique constraints ----------------------------- @@ -636,6 +634,10 @@ Miscellaneous * The default value of the ``USE_L10N`` setting is changed to ``True``. See the :ref:`Localization section <use_l10n_deprecation>` above for more details. +* As part of the :ref:`move to zoneinfo <whats-new-4.0>`, + :attr:`django.utils.timezone.utc` is changed to alias + :attr:`datetime.timezone.utc`. + .. _deprecated-features-4.0: Features deprecated in 4.0 diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt index bf97d40761..53e2af24df 100644 --- a/docs/topics/i18n/timezones.txt +++ b/docs/topics/i18n/timezones.txt @@ -19,8 +19,8 @@ practice to store data in UTC in your database. The main reason is daylight saving time (DST). Many countries have a system of DST, where clocks are moved forward in spring and backward in autumn. If you're working in local time, you're likely to encounter errors twice a year, when the transitions happen. -This probably doesn't matter for your blog, but it's a problem if you over-bill -or under-bill your customers by one hour, twice a year, every year. The +This probably doesn't matter for your blog, but it's a problem if you overbill +or underbill your customers by one hour, twice a year, every year. The solution to this problem is to use UTC in the code and use local time only when interacting with end users. |