summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristopher Luc <chris.luc.dev@gmail.com>2015-03-21 17:45:42 -0700
committerMarkus Holtermann <info@markusholtermann.eu>2015-03-29 23:40:45 +0200
commit19ddf59b264aed7b173a7ec177b9353432334a94 (patch)
tree3fc74f7c4c1d9b2798ca35e489b81c5e3eb387ef
parent7c7d29adbeb078655f9133a14d865955d1d26048 (diff)
[1.7.x] Fixed #24281 -- Improved docs for timezone handling for auto_now and auto_now_add
Thanks djbug for the report and Aymeric Augustin and Carl Meyer for the review. Backport of 8119876d4a533fbc2ba4d1c30eaddbcc28119488 from master
-rw-r--r--docs/ref/models/fields.txt9
-rw-r--r--docs/topics/i18n/timezones.txt4
2 files changed, 11 insertions, 2 deletions
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 9510025e5c..4b33c9cdb0 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -501,6 +501,15 @@ message key.
``True`` will cause the field to have ``editable=False`` and ``blank=True``
set.
+.. note::
+ The ``auto_now`` and ``auto_now_add`` options will always use the date in
+ the :ref:`default timezone <default-current-time-zone>` at the moment of
+ creation or update. If you need something different, you may want to
+ consider simply using your own callable default or overriding ``save()``
+ instead of using ``auto_now`` or ``auto_now_add``; or using a
+ ``DateTimeField`` instead of a ``DateField`` and deciding how to handle the
+ conversion from datetime to date at display time.
+
``DateTimeField``
-----------------
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index f2b7c30a74..b7eeb3afb2 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -9,13 +9,13 @@ Time zones
Overview
========
-When support for time zones is enabled, Django stores date and time
+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.
This is handy if your users live in more than one time zone and you want to
-display date and time information according to each user's wall clock.
+display datetime information according to each user's wall clock.
Even if your Web site is available in only one time zone, it's still good
practice to store data in UTC in your database. One main reason is Daylight