#25937: Failure when using expressions.DateTime on NULL values and aggregating
-------------------------------------+-------------------------------------
     Reporter:  trecouvr             |                    Owner:
                                     |  cheryllium
         Type:  Bug                  |                   Status:  assigned
    Component:  Database layer       |                  Version:  1.9
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  aggregate timezone   |             Triage Stage:  Accepted
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by cheryllium):

 Right now the remaining issue is with this query and on SQLite only:

 {{{
 with_null_fields = DTModel.objects.annotate(
     extracted=TruncTime('start_time', tzinfo=timezone.UTC())
 ).values('extracted').annotate(c=Count('pk'))
 }}}

 It generates the following SQL:

 {{{
 SELECT django_datetime_cast_time("db_functions_dtmodel"."start_time", UTC)
 AS "extracted", COUNT("db_functions_dtmodel"."id") AS "c" FROM
 "db_functions_dtmodel" GROUP BY
 django_datetime_cast_time("db_functions_dtmodel"."start_time", UTC)
 }}}

 If you run this test (using my branch linked in the above pull request),
 you will see an error that only happens with SQLite as the db:

 {{{
 PYTHONPATH=...:$PYTHONPATH ./runtests.py
 db_functions.test_datetime.DateFunctionWithTimeZoneTests.test_trunc_time_func
 }}}

 This is because the generated query ends up calling
 `django_datetime_cast_time` with a time as its first argument
 (`start_time` contains only the time data, not a date).

 This argument is passed from `django_datetime_cast_time` to
 `_sqlite_datetime_parse` to `typecast_timestamp` (defined in
 django/db/backends/utils.py). This last function parses it to a
 `datetime.time` object, which is returned.

 After the `datetime.time` is returned, the caller proceeds to pass it to
 `timezone.localtime`, which then throws an exception as it expects a
 `datetime.datetime` object, not a `datetime.time`.

 I am not sure what the correct behavior should be in this situation. I
 suppose it doesn't make a lot of sense to adjust a time alone according to
 a time zone. Should we ignore the timezone in this case?

 I hope I have articulated this clearly. Please ping if you have any
 questions I might be able to answer.

 I'll take a look at how this test is handled with the other databases (as
 the test passes with those), but any guidance would be appreciated as it
 can be dizzying to dig through these functions :)

--
Ticket URL: <https://code.djangoproject.com/ticket/25937#comment:6>
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 post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bbbcd1c229d63770ff61d0ae21aeace1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to