#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.