如果我运行python -Wall manage.py test此警告（以及类似）发生：
/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py:1453:
RuntimeWarning: DateTimeField SignUpUser.signup_time received a naive datetime (2018-03-17 21:27:22.620074) while time zone support is active.RuntimeWarning)
但是，对于模型SignUpUser没有这样的领域了。这就是所谓的signup_timestamp。在其他领域出现同样的错误。要解决这些我改变datetime.now内置的时区考虑timezone.now Django的。但是，错误消息也不会消失。我想这是因为旧的迁移。
该网站已经在生产，但只有我正在开发。我应该怎样解决这个问题？重置所有迁移文件，并与--fake-初始重做迁移？
我遇到了类似的问题。我曾与一个DateTimeField datetime.now定义的默认值，并切换到timezone.now。我每个模型的变化（proably对它们进行测试）之后创建的迁移。这导致了一个迁移没有时区（field=models.DateTimeField(default=datetime.datetime(2018, 8, 2, 22, 15, 4, 702061)),）定义的默认值，并在下一次迁移会解决这个问题，并添加时区（field=models.DateTimeField(default=datetime.datetime(2018, 8, 3, 19, 22, 32, 951341, tzinfo=utc)),）。
当运行测试的模型（python manage.py test app_name），则导致：[...]/django/db/models/fields/__init__.py:1423: RuntimeWarning: DateTimeField Job.sub_date received a naive datetime (2018-08-02 22:15:04.702061) while time zone support is active.
这似乎是Django的尝试将迁移应用到该时区的意识已经定义的数据库。不知道为什么它如此，但，这似乎是怎么回事。
为了防止发生，我不得不壁球迁移到那个改变了DateTimeFiled的默认值进行时区意识到迁移警告。在我的情况，这是迁移0007，而0006添加的默认值没有时区的认识。因此，要创建壁球的命令是：
$ python manage.py squashmigrations app_name 0007
此创建了包含通过0001_squashed_0007_auto_20180803_2122.py由迁移0001所做的所有更改的新的迁移文件0007。作为documentation说，这种情况发生在一个优化的方式，使得只有一个系列迁移的最后的结果是建立一个没有中间步骤。
在新安装，而不是运行单独迁移通过0001 0007只有新压扁的迁移将会运行。你应该保持原有的迁移有一段时间，以确保挤压没有引入任何问题：
一旦你压扁迁移，则应提交它，它取代了一起迁移而这种改变分配给应用程序的所有运行实例，确保它们运行迁移到存储在他们的数据库中的变化。
然后，您必须转型压扁迁移到由正常的迁移：
- 删除所有它取代了迁移文件。
- 更新依赖于删除迁移所有迁移依赖于压扁迁移来代替。
- 删除内容替换迁移类压扁迁移的属性（这是Django是如何告诉，这是一个压扁的迁移）。