Changes between Initial Version and Version 1 of Ticket #31638


Ignore:
Timestamp:
May 28, 2020, 7:37:05 AM (4 years ago)
Author:
Matthijs Kooijman
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #31638 – Description

    initial v1  
    77
    88I realize that Mysql, Sqlite and Oracle are documented to not support timezones, but that should only mean that they do not explicitly *store* timezone information along with `datetime` fields and that keeping timezones consistent relies on external configuration instead. Given that, I think that `Now()` should still behave as expected on all databases.
     9
     10=== Testcase showing the problem
     11I've created a draft pullrequest with a testcase to show this problem here: https://github.com/django/django/pull/12991
     12
     13With that testcase, on my system (mariadb 5.5.5-10.3.22-MariaDB-0ubuntu0.19.10.1, CEST/UTC+0200 timezone), I see that:
     14 - With sqlite and `USE_TZ=False`: fails because `Now()` is in UTC and Django uses its configured `TIME_ZONE` (`America/Chicago`).
     15 - With sqlite and `USE_TZ=True`: works, since `Now()` is in UTC and Django defaults to UTC.
     16 - With sqlite and `USE_TZ=True` and database `TIME_ZONE=Europe/Amsterdam`: fails, since `Now()` is in UTC and Django now uses `Europe/Amsterdam` (for this, I set `TIME_ZONE` in the `DATABASES` of my settings manually, not sure if I could do that inside a testcase).
     17 - With Mysql and `USE_TZ=True`: fails, since Mysql uses the system timezone (UTC+0200) and Django uses UTC.
     18 - With Mysql and `USE_TZ=False`: fails, since Mysql uses the system timezone (UTC+0200) and Django uses its configured `TIME_ZONE` (`America/Chicago`).
     19 - With Postgresql, all tests succeed.
     20
     21See the pullrequest for detailed test output, including some debug prints that help confirm all of the above observations.
    922
    1023=== Potential fix: Setting the session timezone
    … …  
    3346Not really satisfactory, but I guess `django.db.models.functions.Now` could document this limitation and recommend to use `timezone.now()` instead (which I think could be used everywhere `Now()` could be used, except maybe as a default value, and produce nearly identical results).
    3447
    35 === Testcase showing the problem
    36 I've created a draft pullrequest with a testcase to show this problem here: https://github.com/django/django/pull/12991
    37 
    38 With that testcase, on my system (mariadb 5.5.5-10.3.22-MariaDB-0ubuntu0.19.10.1, CEST/UTC+0200 timezone), I see that:
    39  - With sqlite and `USE_TZ=False`: fails because `Now()` is in UTC and Django uses its configured `TIME_ZONE` (`America/Chicago`).
    40  - With sqlite and `USE_TZ=True`: works, since `Now()` is in UTC and Django defaults to UTC.
    41  - With sqlite and `USE_TZ=True` and database `TIME_ZONE=Europe/Amsterdam`: fails, since `Now()` is in UTC and Django now uses `Europe/Amsterdam` (for this, I set `TIME_ZONE` in the `DATABASES` of my settings manually, not sure if I could do that inside a testcase).
    42  - With Mysql and `USE_TZ=True`: fails, since Mysql uses the system timezone (UTC+0200) and Django uses UTC.
    43  - With Mysql and `USE_TZ=False`: fails, since Mysql uses the system timezone (UTC+0200) and Django uses its configured `TIME_ZONE` (`America/Chicago`).
    44 
    45 See the pullrequest for detailed test output, including some debug prints that help confirm all of the above observations.
    46 
    4748=== Conclusion
    4849For now, I'm going to switch to using `timezone.now()`, which I think should fix my immediate problem, but it would be nice if this could work as expected out of the box. As for applying a fix, I do not think I am familiar enough with the db code to really tell what would be the best solution or implement it (nor will I have the time for it, I'm afraid).
Back to Top