Commit 19ddf59b authored by Christopher Luc's avatar Christopher Luc Committed by Markus Holtermann
Browse files

[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 8119876d from master
parent 7c7d29ad

docs/ref/models/fields.txt

+9 −0
Original line number Diff line number Diff line
@@ -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``

-----------------

docs/topics/i18n/timezones.txt

+2 −2
Original line number Diff line number Diff line
@@ -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