id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
22549	DateTimeField raises timezone awareness related RuntimeWarnings when it should'nt	matias@…	nobody	"I've experienced some issues with wrong RuntimeWarnings about naive datetimes being raised when the 
datetime I was using was perfectly timezone aware and I think I found the reason why:

In django/db/models/fields/init.py file, inside the definition of DateTimeField.to_python method, 
the timezone awareness of a datetime is checked calling the isinstance function.


{{{
if isinstance(value, datetime.date):
    value = datetime.datetime(value.year, value.month, value.day)
    if settings.USE_TZ:
        # For backwards compatibility, interpret naive datetimes in
        # local time. This won't work during DST change, but we can't
        # do much about it, so we let the exceptions percolate up the
        # call stack.
        warnings.warn(""DateTimeField %s.%s received a naive datetime ""
                      ""(%s) while time zone support is active."" %
                      (self.model.__name__, self.name, value),
                      RuntimeWarning)
}}}


Is true that, as said here https://docs.python.org/2.7/library/datetime.html#available-types,
""objects of the date type are always naive"", but is wrong to use isinstance since all datetime.datetime
objects are also instances of datetime.date because datetime.datetime is a subclass of datetime.date
(which I think is confusing since breakes the OOP intuition that says that class inheritance should
describe ""is a"" relationships).

A posible solution is to compare using type(value) == datetime.date or, more clearly, check using django.utils.is_naive"	Bug	closed	Database layer (models, ORM)		Normal	worksforme		matias@…	Accepted	0	0	0	0	0	0