Would a per-database setting "TZ_AWARE_DATETIMES" help address the
backwards compatability issue? It would default to True but would allow
those who find the migration painful to do that on their own schedule.
On Friday, April 29, 2016 at 2:06:34 AM UTC-7, Anssi Kääriäinen wrote:
>
> I'm mildly
I'm mildly in favor of b), seems like most projects would want that anyways.
If there is a really easy way for picking tz conversions per cursor,
then that could be a good approach, too. Something like cursor =
connection.cursor(convert_tz=True) might work. I know then MySQL would
have a bit diffe
Hello Bryce,
Oops! I didn’t realize that conversions were a parameter of the database
connection on MySQL :-( So, yes, it is technically possible to implement the
solution you’re describing.
However I’m not positive that we should make this change. There’s an argument
to be made that database
Also to directly answer the question, I'm talking abour cursor.execute()
On Thursday, April 28, 2016 at 3:48:21 PM UTC-7, Bryce Drennan wrote:
>
> I'm wondering if we're using the term "global" slightly differently.
>
> Yes, prior to the changes removing converters, Django had these converters
I'm wondering if we're using the term "global" slightly differently.
Yes, prior to the changes removing converters, Django had these converters
globally applied to all mysql connections that it created. However, they
didn't apply to mysql connections created outside of django, nor did django
Hi Bryce,
#19738 is unrelated to the problem you’re describing. It was fixed in d9521f66
which removed adapters i.e. transformations of parameters passed to the
database.
You’re talking about the removal of converters i.e. transformations of values
returned by the database. It is discussed in
