Merge remote-tracking branch 'upstream/main'

Author: dan-mm

django/core/management/base.py

@@ -345,7 +345,7 @@ def create_parser(self, prog_name, subcommand, **kwargs):
             parser,
             "--traceback",
             action="store_true",
-            help="Raise on CommandError exceptions.",
+            help="Display a full stack trace on CommandError exceptions.",
         )
         self.add_base_argument(
             parser,

docs/ref/models/fields.txt

@@ -798,6 +798,15 @@ Any combination of these options will result in an error.
     instead of a ``DateField`` and deciding how to handle the conversion from
     datetime to date at display time.
 
+.. warning:: Always use :class:`DateField` with a ``datetime.date`` instance.
+
+    If you have a ``datetime.datetime`` instance, it's recommended to convert
+    it to a ``datetime.date`` first. If you don't, :class:`DateField` will
+    localize the ``datetime.datetime`` to the :ref:`default timezone
+    <default-current-time-zone>` and convert it to a ``datetime.date``
+    instance, removing its time component. This is true for both storage and
+    comparison.
+
 ``DateTimeField``
 -----------------
 
@@ -810,6 +819,16 @@ The default form widget for this field is a single
 :class:`~django.forms.DateTimeInput`. The admin uses two separate
 :class:`~django.forms.TextInput` widgets with JavaScript shortcuts.
 
+.. warning:: Always use :class:`DateTimeField` with a ``datetime.datetime``
+    instance.
+
+    If you have a ``datetime.date`` instance, it's recommended to convert it to
+    a ``datetime.datetime`` first. If you don't, :class:`DateTimeField` will
+    use midnight in the :ref:`default timezone <default-current-time-zone>` for
+    the time component. This is true for both storage and comparison. To
+    compare the date portion of a :class:`DateTimeField` with a
+    ``datetime.date`` instance, use the :lookup:`date` lookup.
+
 ``DecimalField``
 ----------------
 

docs/topics/i18n/timezones.txt

@@ -9,7 +9,10 @@ Overview
 
 When support for time zones is enabled, Django stores datetime information in
 UTC in the database, uses time-zone-aware datetime objects internally, and
-translates them to the end user's time zone in templates and forms.
+converts them to the end user's time zone in forms. Templates will use the
+:ref:`default time zone <default-current-time-zone>`, but this can be updated
+to the end user's time zone through the use of :ref:`filters and tags
+<time-zones-in-templates>`.
 
 This is handy if your users live in more than one time zone and you want to
 display datetime information according to each user's wall clock.

tests/migrations/test_operations.py

@@ -1380,8 +1380,8 @@ def test_add_field(self):
         self.assertEqual(sorted(definition[2]), ["field", "model_name", "name"])
 
     @skipUnlessDBFeature("supports_stored_generated_columns")
-    def test_add_generate_field(self):
-        app_label = "test_add_generate_field"
+    def test_add_generated_field(self):
+        app_label = "test_add_generated_field"
         project_state = self.apply_operations(
             app_label,
             ProjectState(),