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

[bobhaugen]

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]

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]

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]

Oh, and Django 1.4.1...sorry.

[Chris Cogdon]

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]

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]

Okay, so when you create your datetimes, are you defining them with a timezone ?

[Bob Haugen]

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]

But sincerely, Chris, thanks for hanging in there on this. I baffled.

[Chris Cogdon]

Throw the code up somewhere I can see the results for myself?

[Bob Haugen]

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]

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]

I'm running ./manage.py test valueaccounting

[Bob Haugen]

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]

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]

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]

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]

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]

Awesome. Thanks for the update.

[Tom Evans]

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]

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