getting "DateTimeField received a naive datetime" error but have no DateTimeFields

577 views
Skip to first unread message

bobhaugen

unread,
Dec 14, 2012, 12:46:33 PM12/14/12
to django...@googlegroups.com
RuntimeWarning: DateTimeField received a naive datetime (2012-12-14 17:39:38.878379) while time zone support is active.

This is happening in my tests, but not in normal code.

From dropping a trace in, it looks like it is happening before the test setup even runs.

I double-checked my models,  not a DateTimeField in the lot. Nor anywhere else in my code except for South migrations, where it is found in     models['auth.user']. (But I'm not creating any Users in my test code, either...)

The tests run ok, but the error messages will be disconcerting to people who install my open-source project code.

Any clues?

Thanks.

Chris Cogdon

unread,
Dec 14, 2012, 2:27:03 PM12/14/12
to django...@googlegroups.com
Would be nice to know what function's raising that error, and where the value came from. Requesting traceback, database type (tried it with more than one database type), and other information.

bobhaugen

unread,
Dec 14, 2012, 2:43:09 PM12/14/12
to django...@googlegroups.com
Thanks for the reply.


On Friday, December 14, 2012 1:27:03 PM UTC-6, Chris Cogdon wrote:
Would be nice to know what function's raising that error, and where the value came from. Requesting traceback, database type (tried it with more than one database type), and other information.

It's in a test.   No real traceback, just a bunch of the same error messages:

./manage.py test valueaccounting
Creating test database for alias 'default'...
/home/bob/.virtualenvs/vn2/lib/python2.6/site-packages/django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField received a naive datetime (2012-12-14 19:41:27.469600) while time zone support is active.
  RuntimeWarning)
/home/bob/.virtualenvs/vn2/lib/python2.6/site-packages/django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField received a naive datetime (2012-12-14 19:41:27.507916) while time zone support is active.
  RuntimeWarning)

Database is sqlite. 

bobhaugen

unread,
Dec 14, 2012, 2:44:04 PM12/14/12
to django...@googlegroups.com
Oh, and Django 1.4.1...sorry.

Chris Cogdon

unread,
Dec 14, 2012, 4:02:22 PM12/14/12
to django...@googlegroups.com
Nothing definitive, but from checking the location of the code that is raising the warning, I suspect one of the following:

1. USE_TZ is not set in your production code, but _is_ set in your settings file for your tests. Of course, your code should work either way for the most flexibility.

2. The test database you are using (ie, from fixtures or otherwise) has non-timezone dates and times, and USE_TZ is set in your testing settings files. In these cases your test data and the USE_TZ setting should be matching.

Bob Haugen

unread,
Dec 14, 2012, 4:05:19 PM12/14/12
to django...@googlegroups.com
On Fri, Dec 14, 2012 at 3:02 PM, Chris Cogdon <ch...@cogdon.org> wrote:
> Nothing definitive, but from checking the location of the code that is
> raising the warning, I suspect one of the following:
>
> 1. USE_TZ is not set in your production code, but _is_ set in your settings
> file for your tests. Of course, your code should work either way for the
> most flexibility.

USE_TZ is set in settings.py (in production code)
>
> 2. The test database you are using (ie, from fixtures or otherwise) has
> non-timezone dates and times, and USE_TZ is set in your testing settings
> files. In these cases your test data and the USE_TZ setting should be
> matching.

No fixtures. Creating test objects in the test setup code.

Chris Cogdon

unread,
Dec 14, 2012, 6:42:37 PM12/14/12
to django...@googlegroups.com
Okay, so when you create your datetimes, are you defining them with a timezone ?

Bob Haugen

unread,
Dec 14, 2012, 6:51:05 PM12/14/12
to django...@googlegroups.com
On Fri, Dec 14, 2012 at 5:42 PM, Chris Cogdon <ch...@cogdon.org> wrote:
> Okay, so when you create your datetimes, are you defining them with a
> timezone ?

I tried that; did not make any difference. The error messages came up
before any of the test setup code ran. (I put a pdb trace in at the
start; the error messages had already happened.)

I did not create any datetimes. I did create dates, but they did not
cause any errors. The errors had already arisen way before then.

Bob Haugen

unread,
Dec 14, 2012, 6:52:11 PM12/14/12
to django...@googlegroups.com
But sincerely, Chris, thanks for hanging in there on this. I baffled.

Chris Cogdon

unread,
Dec 14, 2012, 7:07:18 PM12/14/12
to django...@googlegroups.com
Throw the code up somewhere I can see the results for myself?

Bob Haugen

unread,
Dec 14, 2012, 7:09:25 PM12/14/12
to django...@googlegroups.com
On Fri, Dec 14, 2012 at 6:07 PM, Chris Cogdon <ch...@cogdon.org> wrote:
> Throw the code up somewhere I can see the results for myself?

https://github.com/valnet/valuenetwork/blob/master/valuenetwork/valueaccounting/tests.py

Chris Cogdon

unread,
Dec 14, 2012, 8:06:39 PM12/14/12
to django...@googlegroups.com
Checked out the code and attempted to run "manage.py test", but clearly I don't have all the required modules installed. Sure is a lot of them!

Are you running tests using "manage.py test" ??  If so, have you considered that its not _your_ code that is showing up those errors, but that of one of the other modules? Take your module out of INSTALLED_APPS and re-run test. Still happening? Then it ain't you! :)

Bob Haugen

unread,
Dec 14, 2012, 8:25:00 PM12/14/12
to django...@googlegroups.com
I'm running ./manage.py test valueaccounting

Bob Haugen

unread,
Dec 14, 2012, 8:27:04 PM12/14/12
to django...@googlegroups.com
Also, I recognize this is way beyond the call of duty, but if you
really want to reproduce the problem, you might need to follow:
https://github.com/valnet/valuenetwork/blob/master/docs/install.txt

Chris Cogdon

unread,
Dec 15, 2012, 2:16:53 AM12/15/12
to django...@googlegroups.com
Well, I did all that (and I learned a few things in the process that will be useful for my own project... thank you!)

I never got the warnings you got, but I got three errors along the lines of:

======================================================================
ERROR: test_mismatched_agents1 (valuenetwork.valueaccounting.tests.CompensationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ccogdon/dev/valuenetwork/valuenetwork/valuenetwork/valueaccounting/tests.py", line 30, in setUp
    self.agent_A.save()
  File "/Users/ccogdon/dev/valuenetwork/valuenetwork/valuenetwork/valueaccounting/models.py", line 196, in save
    super(EconomicAgent, self).save(*args, **kwargs)
  File "/Users/ccogdon/dev/valuenetwork/lib/python2.7/site-packages/django/db/models/base.py", line 463, in save
    self.save_base(using=using, force_insert=force_insert, force_update=force_update)
  File "/Users/ccogdon/dev/valuenetwork/lib/python2.7/site-packages/django/db/models/base.py", line 551, in save_base
    result = manager._insert([self], fields=fields, return_id=update_pk, using=using, raw=raw)
  File "/Users/ccogdon/dev/valuenetwork/lib/python2.7/site-packages/django/db/models/manager.py", line 203, in _insert
    return insert_query(self.model, objs, fields, **kwargs)
  File "/Users/ccogdon/dev/valuenetwork/lib/python2.7/site-packages/django/db/models/query.py", line 1576, in insert_query
    return query.get_compiler(using=using).execute_sql(return_id)
  File "/Users/ccogdon/dev/valuenetwork/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 910, in execute_sql
    cursor.execute(sql, params)
  File "/Users/ccogdon/dev/valuenetwork/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 337, in execute
    return Database.Cursor.execute(self, query, params)
IntegrityError: valueaccounting_economicagent.created_date may not be NULL


Want me to grab a different revision from git ?

Bob Haugen

unread,
Dec 15, 2012, 5:13:29 AM12/15/12
to django...@googlegroups.com
On Sat, Dec 15, 2012 at 1:16 AM, Chris Cogdon <ch...@cogdon.org> wrote:
> I never got the warnings you got, but I got three errors along the lines of:
> IntegrityError: valueaccounting_economicagent.created_date may not be NULL

> Want me to grab a different revision from git ?

Fixed that one. You could do a git pull if you really want. And huge
thanks for all the work.

But I wonder why I never got that error (which was clearly an error,
which I have been oblivious about), and you did not get the naive
datetime warnings...?

Some diff between python2.7 and python2.6? I'll have a local friend
try it later today.

Bob Haugen

unread,
Dec 15, 2012, 9:45:28 AM12/15/12
to django...@googlegroups.com
Ok, got a friend to try this using python2.7 and did not get the naive
datetime warnings.

So I conclude it is something about either python2.6 or something else
in my local environment, and not a proper django-users concern.

P.S. Chris, thanks again for all the help. You're really active
responding on django-users lately.

bobhaugen

unread,
Dec 16, 2012, 6:56:22 AM12/16/12
to django...@googlegroups.com
Wrapping this up:  the problem was caused by South, happened in migrate (found via stack trace).  When I upgraded South, the problem went away.

Chris Cogdon

unread,
Dec 16, 2012, 3:34:04 PM12/16/12
to django...@googlegroups.com
Awesome. Thanks for the update.

Tom Evans

unread,
Dec 17, 2012, 9:27:28 AM12/17/12
to django...@googlegroups.com
Following the thread I see that you have figured out where and why
this is coming from. There is a simple tip you can use to speed this
up in future, simply run python with warnings set to error, and any
Warnings will be converted into RuntimeErrors - so you get a lovely
stack trace showing exactly how and when the warning was issued.

You can configure python to stop only on certain Warnings, but the
simplest way is to turn all Warnings into Errors:

python -W error manage.py ....

Full details on what you can specify with -W here:

http://docs.python.org/2/library/warnings.html#the-warnings-filter

Cheers

Tom

bobhaugen

unread,
Dec 18, 2012, 9:51:33 AM12/18/12
to django...@googlegroups.com, teva...@googlemail.com
Tom, thank you for that very useful tip!  My feeble python-fu has now been strengthened.

On Monday, December 17, 2012 8:27:28 AM UTC-6, Tom Evans wrote
Reply all
Reply to author
Forward
0 new messages