t;>
> >> I wrote in a later commit that values returned by .raw() wouldn’t be
> >> affected:
> >>
> >>
> https://github.com/django/django/commit/d9521f66b1851b0eacd55bc78f801dc64123e333#diff-c0f4f3a0c26f12ebc2e41904af710f4dR456
>
> >&g
he release notes. That 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
>> p
ould 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 easies
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.exec
entioned by 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.
>
&
oblem
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, at 00:09, Bryce Drennan wrote:
>
> Request
>
> Change executed
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
