[Django] #24822: DateTimeField timezone issue converting default fields
Django
------------------------------+--------------------
Reporter: camiloforero | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------
I wanted to add a default value to a DateTimeField, so I set {{{
default=datetime(2015, 7, 4, 8, 0 ) }}} as an argument. When I ran
makemigrations/migrate, I got a warning about naive timezones. I read
about it and decided to set it as {{{ default=datetime(2015, 7, 4, 8, 0,
tzinfo=timezone.get_default_timezone() ) }}} (I imported
django.utils.timezone) but when I tried to makemigrations and migrate I
got an error {{{ can't compare offset-naive and offset-aware datetimes }}}
from {{{old_field_dec != new_field_dec}}} in django.autodetector.py.
To solve it I had to remove the default from the DateTimeField, migrate
(got a warning again), add it again with the timezone enabled, and migrate
again. That time it worked just fine.
It is worth noting that all of the fields currently in the database had
their values already set, that I am using PostgreSQL and python 2.7.3
--
Ticket URL: <https://code.djangoproject.com/ticket/24822>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
------------------------------+------------------------------------
Reporter: camiloforero | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
Not sure the best to fix this.
--
Ticket URL: <https://code.djangoproject.com/ticket/24822#comment:1>
Django
------------------------------+------------------------------------
Reporter: camiloforero | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
--
Ticket URL: <https://code.djangoproject.com/ticket/24822#comment:2>
Django
Reporter: camiloforero | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MarkusH):
* component: Migrations => Documentation
Comment:
First, it's a rather uncommon use case to define an explicit datetime
instead of `now` (i.e. a function). Second, I only see a possible fix by
special casing datetime handling. That said, I think we should document
this behavior as a known shortcoming until we find a suitable and
practical solution.
--
Ticket URL: <https://code.djangoproject.com/ticket/24822#comment:3>
Django
Reporter: Camilo Ernesto | Owner: nobody
Forero |
Type: Bug | Status: closed
Component: Documentation | Version: 1.8
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => invalid
Comment:
This ticket is not valid anymore. Python 3.5+ no longer raises `TypeError`
when comparing naive and aware `datetimes`:
{{{
Python 3.5.10 (default, Jan 25 2021, 09:05:45)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> import pytz
>>> default=datetime(2015, 7, 4, 8, 0 )
>>> default2=datetime(2015, 7, 4, 8, 0, tzinfo=pytz.UTC)
>>> default != default2
True
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24822#comment:4>