Ticket #17263: 17263.patch

docs/topics/i18n/timezones.txt

@@ -106 +106 @@
 ----------------------------------------
 
 When :setting:`USE_TZ` is ``True``, Django still accepts naive datetime
-objects, in order to preserve backwards-compatibility. It attempts to make them
-aware by interpreting them in the :ref:`default time zone
-<default-current-time-zone>`.
+objects, in order to preserve backwards-compatibility. When the database layer
+receives one, it attempts to make it aware by interpreting it in the
+:ref:`default time zone <default-current-time-zone>` and raises a warning.
 
 Unfortunately, during DST transitions, some datetimes don't exist or are
 ambiguous. In such situations, pytz_ raises an exception. Other
@@ -421 +421 @@
 So the second step is to refactor your code wherever you instanciate datetime
 objects to make them aware. This can be done incrementally.
 :mod:`django.utils.timezone` defines some handy helpers for compatibility
-code: :func:`~django.utils.timezone.is_aware`,
+code: :func:`~django.utils.timezone.now`,
+:func:`~django.utils.timezone.is_aware`,
 :func:`~django.utils.timezone.is_naive`,
 :func:`~django.utils.timezone.make_aware`, and
 :func:`~django.utils.timezone.make_naive`.
 
+Finally, in order to help you locate code that needs upgrading, Django raises
+a warning when you attempt to save a naive datetime to the database. During
+development, you can turn such warnings into exceptions and get a traceback
+by adding to your settings file::
+
+    import warnings
+    warnings.filterwarnings(
+            'error', r"DateTimeField received a naive datetime",
+            RuntimeWarning, r'django\.db\.models\.fields')
+
 .. _pytz: http://pytz.sourceforge.net/
 .. _these issues: http://pytz.sourceforge.net/#problems-with-localtime
 .. _tz database: http://en.wikipedia.org/wiki/Tz_database

django/db/models/fields/__init__.py

@@ -2 +2 @@
 import datetime
 import decimal
 import math
+import warnings
 from itertools import tee
 
 from django.db import connection
@@ -789 +790 @@
             # For backwards compatibility, interpret naive datetimes in local
             # time. This won't work during DST change, but we can't do much
             # about it, so we let the exceptions percolate up the call stack.
+            warnings.warn(u"DateTimeField received a naive datetime (%s)"
+                          u" while time zone support is active." % value,
+                          RuntimeWarning)
             default_timezone = timezone.get_default_timezone()
             value = timezone.make_aware(value, default_timezone)
         return value

tests/modeltests/timezones/fixtures/users.xml

@@ -9 +9 @@
         <field type="BooleanField" name="is_staff">True</field>
         <field type="BooleanField" name="is_active">True</field>
         <field type="BooleanField" name="is_superuser">True</field>
-        <field type="DateTimeField" name="last_login">2007-05-30 13:20:10</field>
-        <field type="DateTimeField" name="date_joined">2007-05-30 13:20:10</field>
+        <field type="DateTimeField" name="last_login">2001-01-01 00:00:00+00:00</field>
+        <field type="DateTimeField" name="date_joined">2001-01-01 00:00:00+00:00</field>
         <field to="auth.group" name="groups" rel="ManyToManyRel"></field>
         <field to="auth.permission" name="user_permissions" rel="ManyToManyRel"></field>
     </object>
-</django-objects>
- No newline at end of file
+</django-objects>

tests/modeltests/timezones/tests.py

@@ -3 +3 @@
 import datetime
 import os
 import time
+import warnings
 
 try:
     import pytz
@@ -238 +239 @@
 
     def test_naive_datetime(self):
         dt = datetime.datetime(2011, 9, 1, 13, 20, 30)
-        Event.objects.create(dt=dt)
+        with warnings.catch_warnings(record=True) as recorded:
+            Event.objects.create(dt=dt)
+            self.assertEqual(len(recorded), 1)
+            msg = str(recorded[0].message)
+            self.assertTrue(msg.startswith("DateTimeField received a naive datetime"))
         event = Event.objects.get()
         # naive datetimes are interpreted in local time
         self.assertEqual(event.dt, dt.replace(tzinfo=EAT))
@@ -246 +251 @@
     @skipUnlessDBFeature('supports_microsecond_precision')
     def test_naive_datetime_with_microsecond(self):
         dt = datetime.datetime(2011, 9, 1, 13, 20, 30, 405060)
-        Event.objects.create(dt=dt)
+        with warnings.catch_warnings(record=True) as recorded:
+            Event.objects.create(dt=dt)
+            self.assertEqual(len(recorded), 1)
+            msg = str(recorded[0].message)
+            self.assertTrue(msg.startswith("DateTimeField received a naive datetime"))
         event = Event.objects.get()
         # naive datetimes are interpreted in local time
         self.assertEqual(event.dt, dt.replace(tzinfo=EAT))
@@ -254 +263 @@
     @skipIfDBFeature('supports_microsecond_precision')
     def test_naive_datetime_with_microsecond_unsupported(self):
         dt = datetime.datetime(2011, 9, 1, 13, 20, 30, 405060)
-        Event.objects.create(dt=dt)
+        with warnings.catch_warnings(record=True) as recorded:
+            Event.objects.create(dt=dt)
+            self.assertEqual(len(recorded), 1)
+            msg = str(recorded[0].message)
+            self.assertTrue(msg.startswith("DateTimeField received a naive datetime"))
         event = Event.objects.get()
         # microseconds are lost during a round-trip in the database
         # naive datetimes are interpreted in local time
@@ -294 +307 @@
         self.assertEqual(event.dt, dt)
 
     def test_auto_now_and_auto_now_add(self):
-        now = datetime.datetime.utcnow().replace(tzinfo=UTC)
+        now = timezone.now()
         past = now - datetime.timedelta(seconds=2)
         future = now + datetime.timedelta(seconds=2)
         Timestamp.objects.create()