#34699: Filtering on annotated TruncSecond expression gives unexpected result.
-------------------------------------+-------------------------------------
Reporter: Stefan | Owner: Wes P.
Type: | Status: assigned
Cleanup/optimization |
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jacob Walls):
Replying to [comment:17 Simon Charette]:
> Assuming we reach consensus that we want to make this behavior less of a
footgun we could introduce a deprecation towards making `Trunc(tzinfo)` a
required parameter when `USE_TZ = True; TIME_ZONE != "UTC"` to eventually
make it default to `datetime.timezone.utc` when the deprecation period
ends.
I think that makes good sense because:
- Elsewhere we advertise if you're using Postgres, that you can "switch
freely" between `USE_TZ` `True` vs. `False`, but not so if
`Extract`/`Trunc` start behaving differently:
> As a consequence, if you're using PostgreSQL, you can switch between
`USE_TZ = False` and `USE_TZ = True` freely.
- We also suggest you should be comparing UTC to UTC in general, and only
converting to local time last-minute, for humans:
> You should only use local time when you're interacting with humans, and
the template layer provides :ref:`filters and tags <time-zones-in-
templates>` to convert datetimes to the time zone of your choice.
- Finally, this would probably fix the
[https://github.com/django/django/pull/18983#issuecomment-3715528301
broken situation] I found last week where `create()` and `bulk_create()`
on SQLite behave differently when a field's `db_default` uses one of these
expressions. SQLite doesn't support the `DEFAULT` keyword for bulk
creates, so we have to emulate the SQL, but if you've altered `USE_TZ` or
`TIME_ZONE` since deploying the field, the SQL will be different than your
deployed database default. Maybe we can teach the migration autodetector
to check `TIME_ZONE` to catch this, but otherwise, forcing more people to
be explicit if they don't want `tzinfo=UTC` would be a help.
However, all of that should probably go through the forum first, and not
Trac, so I'll try to get a topic posted over there separately.
--
Ticket URL: <https://code.djangoproject.com/ticket/34699#comment:24>
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/0107019bb41faba3-001a6099-7665-406d-83ec-0af3b7b565db-000000%40eu-central-1.amazonses.com.
