#37013: Omitting tzinfo argument to Trunc & Extract with USE_TZ = True and
TIME_ZONE != UTC creates ambiguity for migrations
-------------------------------------+-------------------------------------
Reporter: Jacob Walls | Owner: (none)
Type: Bug | Status: new
Component: Database layer | Version: 6.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: tzinfo, TIME_ZONE | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Jacob Walls:
Old description:
> The `Trunc()` and `Extract()` database functions apply timezone
> conversions if `USE_TZ = True`. When the `tzinfo` argument is omitted,
> the timezone is inferred from `settings.TIME_ZONE`. This information is
> not captured by migrations, meaning that if `settings.TIME_ZONE` changes
> over the life of a project, then the database may never receive a
> corresponding update.
>
> {{{#!py
> from django.db import models
> from django.db.models.functions import ExtractHour, Now
>
> class Person(models.Model):
> hour = models.IntegerField(db_default=ExtractHour(Now()))
> }}}
>
> To reproduce:
> - Change `settings.TIME_ZONE` to "America/Chicago".
> - Make migrations, notice no migration generated.
> - Emulating the database-default python-side (as SQLite must do
> sometimes, see rest of linked forum post) now no longer produces the same
> value as the database.
>
> In this [https://forum.djangoproject.com/t/extract-isnt-safe-to-use-in-
> db-default-on-sqlite-if-time-zone-changes-at-some-point/44781/6 forum
> reply], there was an idea to implement `Trunc/Extract.deconstruct()` to
> deprecate omitting `tzinfo` if serialized into a migration and eventually
> make it default to `get_current_timezone()` when not provided.
New description:
The `Trunc()` and `Extract()` database functions apply timezone
conversions if `USE_TZ = True`. When the `tzinfo` argument is omitted, the
timezone is inferred from `settings.TIME_ZONE`. If these functions are
used in a `db_default` expression, this information is not captured by
migrations, meaning that if `settings.TIME_ZONE` changes over the life of
a project, then the database may never receive a corresponding update.
{{{#!py
from django.db import models
from django.db.models.functions import ExtractHour, Now
class Person(models.Model):
hour = models.IntegerField(db_default=ExtractHour(Now()))
}}}
To reproduce:
- Change `settings.TIME_ZONE` to "America/Chicago".
- Make migrations, notice no migration generated.
- Emulating the database-default python-side (as SQLite must do sometimes,
see rest of linked forum post) now no longer produces the same value as
the database.
In this [https://forum.djangoproject.com/t/extract-isnt-safe-to-use-in-db-
default-on-sqlite-if-time-zone-changes-at-some-point/44781/6 forum reply],
there was an idea to implement `Trunc/Extract.deconstruct()` to deprecate
omitting `tzinfo` if serialized into a migration and eventually make it
default to `get_current_timezone()` when not provided.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/37013#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019d4032a83e-c240864c-096c-49ca-acd1-de494ffe7e34-000000%40eu-central-1.amazonses.com.
