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:
parent
5b52376d9f
commit
acfc7e3a73
@ -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
|
||||||
|
Loading…
x
Reference in New Issue
Block a user