Opened 10 years ago
Closed 4 years ago
#24822 closed Bug (invalid)
Autodetector crashes on add/removal of tzinfo from DateTimeField default
Reported by: | Camilo Ernesto Forero | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 1.8 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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
Change History (4)
comment:1 by , 10 years ago
Summary: | DateTimeField timezone issue converting default fields → Autodector crashes on add/removal of tzinfo from DateTimeField default |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 10 years ago
Summary: | Autodector crashes on add/removal of tzinfo from DateTimeField default → Autodetector crashes on add/removal of tzinfo from DateTimeField default |
---|
comment:3 by , 10 years ago
Component: | Migrations → Documentation |
---|
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.
comment:4 by , 4 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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
Not sure the best to fix this.