12ebc2e41904af710f4dR456
>
> >>
> >> I’d like to make sure we agree on what your problem is exactly before
> >> investigating further. When you say "raw mysql queries”, do you mean
> >> MyModel.objects.raw(…) or cursor.execute(…)?
> >>
> >> The
would be annoying :-(
>
> The latter is the documented behavior, which doesn’t preclude discussing
> improvements, but at least means things work as intended.
>
> As mentioned by Carl in the mailing list thread, if you’re having a problem
> with `cursor.execute()`, the easiest
;>
>> The latter is the documented behavior, which doesn’t preclude discussing
>> improvements, but at least means things work as intended.
>>
>> As mentioned by Carl in the mailing list thread, if you’re having a
>> problem with `cursor.execute()`, the easiest solutio
Carl in the mailing list thread, if you’re having a
> problem with `cursor.execute()`, the easiest solution is to reinstall
> yourself the same global converter Django used to install. Is that what you
> meant by “monkey-patching Django”?
>
> --
> Aymeric.
>
> On 20 Apr 2016, a
> Change executed raw mysql queries to return timezone aware datetimes.
>
> Explanation
>
> Django 1.9 changed so that raw queries executed in mysql do not return
> timezone aware datetimes. Removing this feature now requires that all custom
> SQL queries involvin
Request
Change executed raw mysql queries to return timezone aware datetimes.
Explanation
Django 1.9 changed so that raw queries executed in mysql do not return
timezone aware datetimes. Removing this feature now requires that all
custom SQL queries involving datetimes have special handling
