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

Comment (by akaariai):

 An update about MySQL: it has [http://dev.mysql.com/doc/refman/5.0/en
 /date-and-time-functions.html#function_convert-tz convert_tz] function
 which does something equivalent to AT TIME ZONE. However, there are some
 problems with convert_tz:
   - The timezone table for MySQL has to be loaded, if I understand the
 documentation correctly this is not done by default
   - If you try to convert a datetime using an unknown (to MySQL) timezone
 name, you get null back
   - If the datetime falls out of the range 1970-2038 you will not get any
 conversion, you get the input datetime back.

 So, the convert_tz function would cure the problem for MySQL, assuming the
 datetime converted is in range 1970-2038. That could be documented as
 known limitation. This was the last missing piece of this puzzle:
   - SQLite should be easy to support by using Python code directly in the
 query.
   - PostgreSQL and Oracle should work using AT TIME ZONE syntax. Python
 <-> DB timezone names must match or there must be a converter.
   - MySQL should work with convert_tz (with the above cave-eats), Again
 Python <-> DB timezone names must match or there must be a converter.

 There is a lot of work left to actually implement the above properly for
 all core databases. However, that should be pretty straightforward coding
 to do. The big problem is converting the timezone names from Python to DB
 format. Any ideas how to do that in somewhat clean fashion?

-- 
Ticket URL: <https://code.djangoproject.com/ticket/17260#comment:12>
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.

Reply via email to