mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-31 09:41:08 +00:00
Code Issues 32 Releases Wiki Activity

Added clarifications about the DATABASES.TIME_ZONE setting in docs.

Browse Source 
These include:
 - Doc'd which is the default used when DATABASES.TIME_ZONE is None.
 - Doc'd that the database connection's time zone setting is set for
   PostgreSQL and clarified that it may be necessary to set it to the
   same value as TIME_ZONE.

Co-authored-by: David Smith <39445562+smithdc1@users.noreply.github.com>
Co-authored-by: Natalia Bidart <124304+nessita@users.noreply.github.com>
This commit is contained in:
David Sanders
2023-12-15 04:35:04 +11:00
committed by GitHub
parent 5b52376d9f
commit acfc7e3a73
1 changed files with 15 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/ref/settings.txt
View File

@@ -663,8 +663,10 @@ A string representing the time zone for this database connection or ``None``.
This inner option of the :setting:`DATABASES` setting accepts the same values
as the general :setting:`TIME_ZONE` setting.
When :setting:`USE_TZ` is ``True`` and this option is set, reading datetimes
from the database returns aware datetimes in this time zone instead of UTC.
When :setting:`USE_TZ` is ``True``, reading datetimes from the database
returns aware datetimes with the timezone set to this option's value if not
``None``, or to UTC otherwise.
When :setting:`USE_TZ` is ``False``, it is an error to set this option.
* If the database backend doesn't support time zones (e.g. SQLite, MySQL,
@@ -687,13 +689,18 @@ When :setting:`USE_TZ` is ``False``, it is an error to set this option.
third-party systems connect to the same database and expect to find
datetimes in local time, then you must set this option.
* If the database backend supports time zones (e.g. PostgreSQL), the
``TIME_ZONE`` option is very rarely needed. It can be changed at any time;
the database takes care of converting datetimes to the desired time zone.
* If the database backend supports time zones (e.g., PostgreSQL), then the
database connection's time zone is set to this value.
Setting the time zone of the database connection may be useful for running
raw SQL queries involving date/time functions provided by the database, such
as ``date_trunc``, because their results depend on the time zone.
Although setting the ``TIME_ZONE`` option is very rarely needed, there are
situations where it becomes necessary. Specifically, it's recommended to
match the general :setting:`TIME_ZONE` setting when dealing with raw queries
involving date/time functions like PostgreSQL's ``date_trunc()`` or
``generate_series()``, especially when generating time-based series that
transition daylight savings.
This value can be changed at any time, the database will handle the
conversion of datetimes to the configured time zone.
However, this has a downside: receiving all datetimes in local time makes
datetime arithmetic more tricky — you must account for possible offset