#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-------------------------------------+-------------------------------------
     Reporter:  aaugustin            |                    Owner:  aaugustin
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:  Accepted
     Keywords:                       |      Needs documentation:  0
    Has patch:  0                    |  Patch needs improvement:  0
  Needs tests:  0                    |                    UI/UX:  0
Easy pickings:  0                    |
-------------------------------------+-------------------------------------

Comment (by aaugustin):

 I've started by documented the target public API.

 Conversions/truncations will use the current time zone by default because:
 - aggregation should generally happen in the end user's time zone;
 - it allows using `timezone.override` as shown below.

 The design is sufficiently flexible to deal with all the cases discussed
 above.

 Even "uncooperative" setups (MySQL, Windows) can be made to work with a
 custom tzinfo whose `tzname` returns the appropriate value for the
 database:
 {{{
 qs.datetimes('dt', 'day', timezone=non_standard_tzinfo_object)
 }}}
 {{{
 with timezone.override(non_standard_tzinfo_object):
     qs.filter(dt__day=1)
 }}}

 Using `.datetimes()` doesn't require a custom tzinfo class; the
 appropriate time zone name for the database can be provided directly:
 {{{
 qs.datetimes('dt', 'day', timezone='Non-standard name")
 }}}

 I don't care if MySQL silently returns wrong data when it's misconfigured.
 This isn't worse than all the other data truncation or corruption bugs
 (for instance, when inserting a string longer than the field size) that
 happen with MySQL's default configuration. If you use MySQL and care about
 data integrity, you have to read its manual (and much more).

 Finally I don't see the need for a `get_db_tz_name` method; the standard
 `tzname` suffices.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/17260#comment:23>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to