Hi Carl,
2015-04-13 21:11 GMT+02:00 Carl Meyer mailto:c...@oddbird.net>>:
It would also be possible to put the silent-data-loss aspect of this
change through a deprecation path, by having the existing adapters raise
a deprecation warning on receiving any non-UTC aware datetime for a
couple release
On 13 avr. 2015, at 20:13, Aymeric Augustin
wrote:
> Replacing adapters is a bit more tricky. Removing them causes the two
> regression tests for #17755 to fail. I haven't determined how I can process
> parameters passed to QuerySet.raw(), but since that's part of the ORM, I'm
> optimistic.
Wel
I think this is likely a good plan. There are a number of other places
where we globally register converters/adapters (at least in postgres land)
rather than explicitly registering them on each connection. I'm not sure if
they're an issue in the same way though.
Marc
On 13 April 2015 at 20:11, Ca
On 04/13/2015 12:13 PM, Aymeric Augustin wrote:
[snip]
> Do you think the backwards-incompatibilities are acceptable?
I think so, yes. It really isn't good behavior for Django to be
automatically installing such global adapters and converters.
Perhaps the release notes documenting this backwards-
Hello,
On databases that don't support time zones -- SQLite, MySQL, Oracle (*) -- the
implementation of time zone support I added in Django 1.4 defines:
1. A global converter, e.g. `parse_datetime_with_timezone_support` for SQLite,
which processes values returned by the database for datetime c
