There was a special case in this property to return None when the
database backend supports time zone. However, only the PostgreSQL
backend supports time zones and it never uses this property.
time.monotonic() available from Python 3.3:
- Nicely communicates a narrow intent of "get a local system monotonic
clock time" instead of possible "get a not necessarily accurate Unix
time stamp because it needs to be communicated to outside of this
process/machine" when time.time() is used.
- Its result isn't affected by the system clock updates.
There are two classes of time.time() uses changed to time.monotonic()
by this change:
- measuring time taken to run some code.
- setting and checking a "close_at" threshold for for persistent db
connections (django/db/backends/base/base.py).
Thanks to Josh Smeaton for the idea of implementing server-side cursors
in PostgreSQL from the iterator method, and Anssi Kääriäinen and Kevin
Turner for their previous work. Also Simon Charette and Tim Graham for
review.
This new technique is more straightforward and compatible with test
parallelization, where the effective database connection settings no
longer match settings.DATABASES.
Made it possible to register and run callbacks after a database
transaction is committed with the `transaction.on_commit()` function.
This patch is heavily based on Carl Meyers django-transaction-hooks
<https://django-transaction-hooks.readthedocs.org/>. Thanks to
Aymeric Augustin, Carl Meyer, and Tim Graham for review and feedback.
The primary use case is to interact with a third-party database (not
primarily managed by Django) that doesn't support time zones and where
datetimes are stored in local time when USE_TZ is True.
Configuring a PostgreSQL database with the TIME_ZONE option while USE_TZ
is False used to result in silent data corruption. Now this is an error.