#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 Wes P.):

 Replying to [comment:23 Jacob Walls]:
 > > But then, at least to me, is quite surprising that TruncSecond, which
 is an operation fully occurring in the DB, would not "respect" that "UTC
 invariant" and have the TIME_ZONE setting affecting the results. Does my
 point make sense? Do you have historic information about why TruncSecond
 (and related functions) would not operate with/keep the tz defined in the
 datetime being processed?
 >
 > My guess is simply that it would be a useful convenience for `USE_TZ =
 False` projects, which was the ancient default. There's no reason to
 expect database data to be in UTC if `TIME_ZONE = 'America/Chicago'`
 (default) and `USE_TZ = False`,  so you would probably want this feature:
 >

 When Django added TruncSecond (and related functions) the Postgres
 DATE_TRUNC function was timezone naive. In 2019, Postgres added a timezone
 aware feature.

 > ----
 > My recommendation is that we close this ticket by:
 > 1. Updating the docs for `Extract()` and `Trunc()` with some nuance
 > 2. Fixing the Melbourne details from comment:19
 > 3. Add at least one test for `Extract` or `Trunc` with `USE_TZ = True`
 and `TIME_ZONE` != `UTC` (e.g. the default `America/Chicago`)
 >
 > I'll review the PR with that in mind (it looks already well-scoped to
 those points).

 I'll await your review before making changes to the PR. Wouldn't it be
 better to have a separate ticket for fixing Extract?
-- 
Ticket URL: <https://code.djangoproject.com/ticket/34699#comment:25>
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/0107019bbe4caca4-418e54bb-3877-4333-8bf8-083e6c716219-000000%40eu-central-1.amazonses.com.

Reply via email to