Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#31608 closed Bug (fixed)

forms.DateTimeField parses ISO 8601 datetime with offset as aware when USE_TZ is False.

Reported by: Carlton Gibson Owned by: Hasan Ramezani
Component: Forms Version: 3.1
Severity: Release blocker Keywords:
Cc: Claude Paroz Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The following test fails on 3.1a1.

USE_TZ: If this is set to True, Django will use timezone-aware datetimes internally. Otherwise, Django will use naive datetimes in local time.

diff --git a/tests/forms_tests/field_tests/test_datetimefield.py b/tests/forms_tests/field_tests/test_datetimefield.py
index f0e6ada3c5..ed035497d8 100644
--- a/tests/forms_tests/field_tests/test_datetimefield.py
+++ b/tests/forms_tests/field_tests/test_datetimefield.py
@@ -2,8 +2,8 @@ from datetime import date, datetime
 
 from django.core.exceptions import ValidationError
 from django.forms import DateTimeField
-from django.test import SimpleTestCase
-from django.utils.timezone import get_fixed_timezone, utc
+from django.test import SimpleTestCase, override_settings
+from django.utils.timezone import get_fixed_timezone, is_naive, utc
 
 
 class DateTimeFieldTest(SimpleTestCase):
@@ -65,6 +65,12 @@ class DateTimeFieldTest(SimpleTestCase):
             with self.subTest(value=value):
                 self.assertEqual(f.clean(value), expected_datetime)
 
+    @override_settings(USE_TZ=False)
+    def test_use_tz_false(self):
+        f = DateTimeField()
+        value = '2014-09-23T22:34Z'
+        self.assertTrue(is_naive(f.clean(value)))
+
     def test_datetimefield_clean_invalid(self):
         f = DateTimeField()
         msg = "'Enter a valid date/time.'"

Expected behaviour is to return a naive datetime.

Change History (9)

comment:1 Changed 3 months ago by felixxm

Cc: Claude Paroz added
Triage Stage: UnreviewedAccepted

comment:2 Changed 3 months ago by Hasan Ramezani

Has patch: set
Owner: changed from nobody to Hasan Ramezani
Status: newassigned

comment:3 Changed 3 months ago by Claude Paroz

Repeating what I said on the PR. In my opinion, even if USE_TZ is False, parsing a datetime including timezone information should really keep its timezone. So I'd rather add an admonition to the docs.

comment:4 Changed 3 months ago by Carlton Gibson

So this caused a test failure on Django-Filter.

I've adjusted the test case there to account for the new behaviour.

https://github.com/carltongibson/django-filter/pull/1226

-    @override_settings(USE_TZ=False)
     def test_clean(self):
         w = RangeWidget()
         f = IsoDateTimeRangeField(widget=w)
-        self.assertEqual(
-            f.clean(['2015-01-01T10:30:01.123000+01:00', '2015-01-10T08:45:02.345000+01:00']),
-            slice(datetime(2015, 1, 1, 9, 30, 1, 123000),
-                  datetime(2015, 1, 10, 7, 45, 2, 345000)))
+        expected = slice(
+            datetime(2015, 1, 1, 9, 30, 1, 123000, tzinfo=timezone.utc),
+            datetime(2015, 1, 10, 7, 45, 2, 345000, tzinfo=timezone.utc)
+        )
+        actual = f.clean(['2015-01-01T10:30:01.123000+01:00', '2015-01-10T08:45:02.345000+01:00'])
+        self.assertEqual(expected, actual)

Let's assume we'll go with the docs change.

comment:5 Changed 3 months ago by Hasan Ramezani

Ok, I will create a PR for doc change.

comment:6 Changed 3 months ago by Hasan Ramezani

I created a new PR to change the release note and mention the behavior of forms.DateTimeField per Carlton comment.

comment:7 Changed 3 months ago by Carlton Gibson

Triage Stage: AcceptedReady for checkin

comment:8 Changed 3 months ago by GitHub <noreply@…>

Resolution: fixed
Status: assignedclosed

In 643207ef:

Fixed #31608 -- Doc'd that form ISO 8601 datetime parsing always retains tzinfo.

comment:9 Changed 3 months ago by Carlton Gibson <carlton.gibson@…>

In a6c773a:

[3.1.x] Fixed #31608 -- Doc'd that form ISO 8601 datetime parsing always retains tzinfo.

Backport of 643207efaebbff4e7c3ebcbf9ca49fb6197137e1 from master

Note: See TracTickets for help on using tickets.
Back to Top