Release note edits.4.0/make-zoneinfo-default-timezone-implementation-squashed

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.