#34699: Filtering on annotated TruncSecond expression gives unexpected result.
-------------------------------------+-------------------------------------
     Reporter:  Stefan               |                    Owner:  Francesco
         Type:                       |  Panico
  Cleanup/optimization               |                   Status:  assigned
    Component:  Database layer       |                  Version:  4.2
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Natalia Bidart):

 Replying to [comment:9 Mariusz Felisiak]:
 > It works as documented:
 > - `timezone.now()` - ''"If USE_TZ is True, this will be an aware
 datetime representing the **current time in UTC**. Note that now() will
 always return times in UTC regardless of the value of TIME_ZONE; you can
 use localtime() to get the time in the current time zone."''
 > - `Trunc()` - ''"If a different timezone like Australia/Melbourne is
 active in Django, then the datetime **is converted to the new timezone**
 before the value is truncated."''

 Right, I understand the docs above and how that match the results I got.
 But, at the same time, the first paragraph about "Time Zones" says:

 ''When support for time zones is enabled, Django stores datetime
 information in UTC in the database, uses time-zone-aware datetime objects
 internally, and translates them to the end user’s time zone in templates
 and forms.
 [...]
 Even if your website is available in only one time zone, it’s still good
 practice to store data in UTC in your database.''

 The above aligns perfectly (and makes sense) with `timezone.now` returning
 an aware datetime in UTC. 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?

-- 
Ticket URL: <https://code.djangoproject.com/ticket/34699#comment:10>
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 on the web visit 
https://groups.google.com/d/msgid/django-updates/010701896405df60-757fb278-9734-496c-897c-36577b0522bd-000000%40eu-central-1.amazonses.com.

Reply via email to