#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: SVN
(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 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* cc: anssi.kaariainen@… (added)
Comment:
I have a "POC" version ready. It just adds some timedeltas to the values
where needed. In the database everything is still done at time zone UTC,
we just add the offsets as Python reports them.
The biggest problem with this approach is DST handling. We use the offset
as it is _now_, however the database date might have a different offset
(offset now is 3 hours, in the summer 2 hours). So, we have an error of
one hour for summer dates.
This means that this issue is really hard to fix: if we use current
offsets, we will make an error of one hour across DST (not to mention
actual time zone changes in South America...). That is not correct enough
to call this fixed. We could use "AT TIME ZONE 'tz name'" where available,
but that has just one little problem: we don't know the time zone name.
So, I really can't see an easy fix for this. We could invent a mapping
mechanism for the Python time zone name -> DB time zone name. That isn't
easy either, I believe PostgreSQL can have different time zone names on
Windows and Linux. So, the user should actually define his converter
dictionary in the settings.py, for each database. Or we could have our own
mappings: time zone name -> list of time zones to try. On first connect
inspect what time zones are available. Endless source of bugs, but on the
other hand that isn't much different from supporting the different
locales. This is the best approach available.
After all this MySQL would still be broken. I don't believe there is
anything Django can do to make time zones work correctly together with
dates queries on that database. I really wonder if it is a good idea to
encourage people to use USE_TZ with MySQL. The setup is broken, and as far
as I see, will be broken.
The attached patch is, as said, just a proof of concept, or more correctly
a poor of the concept not working.
--
Ticket URL: <https://code.djangoproject.com/ticket/17260#comment:9>
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
