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 Tim Graham, 10 years ago

Summary: DateTimeField timezone issue converting default fieldsAutodector crashes on add/removal of tzinfo from DateTimeField default
Triage Stage: UnreviewedAccepted

Not sure the best to fix this.

comment:2 by Camilo Ernesto Forero, 10 years ago

Summary: Autodector crashes on add/removal of tzinfo from DateTimeField defaultAutodetector crashes on add/removal of tzinfo from DateTimeField default

comment:3 by Markus Holtermann, 10 years ago

Component: MigrationsDocumentation

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 Mariusz Felisiak, 4 years ago

Resolution: invalid
Status: newclosed

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
Note: See TracTickets for help on using tickets.
Back to Top