1
0
mirror of https://github.com/django/django.git synced 2025-05-29 18:26:29 +00:00

Added clarifications about the DATABASES.TIME_ZONE setting in docs.

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
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

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 This inner option of the :setting:`DATABASES` setting accepts the same values
as the general :setting:`TIME_ZONE` setting. as the general :setting:`TIME_ZONE` setting.
When :setting:`USE_TZ` is ``True`` and this option is set, reading datetimes When :setting:`USE_TZ` is ``True``, reading datetimes from the database
from the database returns aware datetimes in this time zone instead of UTC. 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. 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, * 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 third-party systems connect to the same database and expect to find
datetimes in local time, then you must set this option. datetimes in local time, then you must set this option.
* If the database backend supports time zones (e.g. PostgreSQL), the * If the database backend supports time zones (e.g., PostgreSQL), then the
``TIME_ZONE`` option is very rarely needed. It can be changed at any time; database connection's time zone is set to this value.
the database takes care of converting datetimes to the desired time zone.
Setting the time zone of the database connection may be useful for running Although setting the ``TIME_ZONE`` option is very rarely needed, there are
raw SQL queries involving date/time functions provided by the database, such situations where it becomes necessary. Specifically, it's recommended to
as ``date_trunc``, because their results depend on the time zone. 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 However, this has a downside: receiving all datetimes in local time makes
datetime arithmetic more tricky — you must account for possible offset datetime arithmetic more tricky — you must account for possible offset