mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-12-22 17:16:24 +00:00
Code Issues 25 Releases Wiki Activity

Improved docs for timezone handling for auto_now and auto_now_add

Browse Source 
Thanks djbug for the report and Aymeric Augustin and Carl Meyer for the
review.
This commit is contained in:
Christopher Luc 2015-03-21 17:45:42 -07:00 committed by Markus Holtermann
parent 75430be86f
commit 8119876d4a
2 changed files with 11 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
docs/ref/models/fields.txt
View File

@ -505,6 +505,15 @@ Any combination of these options will result in an error.
``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``
-----------------

4
docs/topics/i18n/timezones.txt
View File

@ -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