Add check for default=now() on Date/Time/DateTimeFields

[taishi@…]

I'm running a model which contains datetime.now() as default value and django keeps thinking that I altered that field.
So everytime I run migrates I get:
Running migrations:

No migrations needed.
Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

If I run makemigrations (once, twice, 20 times) it will always output:
Migrations for 'acb_coins':

0003_auto_20140129_1947.py:

• Alter field last_sync on coin

Model:
class Coin(models.Model):

name = models.CharField(max_length=80)
short_name = models.CharField(max_length=4)
rpc_address = models.CharField(max_length=30)
rpc_port = models.IntegerField(max_length=5)
balance = models.DecimalField(decimal_places=10, max_digits=15)
last_sync = models.DateTimeField(default=datetime.now())

[matt@…]

You don't want to be using datetime.now(): that gets evaluated at the time the module is imported.

You'll want to use datetime.now

[taishi@…]

matt@ comment worked

[Markus Holtermann]

Given the confusion about passing default a datetime object instead of a callable (which solves the problem), I'd like to propose the idea to add a check to Django's check framework to make users aware of these problems that might occur over the time when using datetime.now() instead of datetime.now.

[Marc Tamlyn]

Accepted in principle, but I'm not sure how this could be implemented.

[matheusrosa]

Why don't you use auto_now=True ? Every time you call save(), the last_sync field gets updated with the latest date and time.

[Russell Keith-Magee]

@mjtamlyn - This could be a job for the check framework. We could add a field-level check on the value of default - if the value of default is within some tolerance of now (e.g., within 10 seconds), raise a warning. Since the checks are run almost immediately after the model is loaded, any usage of datetime.now() would return the current date time (or as close as practical). The only way this check would fail would be if someone actually wanted *now*; so, we add it as a warning that can be silenced.

[Russell Keith-Magee]

To that end, it's a pretty easy fix; marking as such.

[Markus Holtermann]

Sounds like a plan, russellm. Do we want to get it into 1.7?

[Russell Keith-Magee]

@MarkusH - No reason it couldn't be in 1.7 - it's a minor fix. We just need a patch :-)

[rkstapenhurst]

Duplicate of #21638

[Markus Holtermann]

This ticket is not a duplicate at all. The intention is to add a check command warning a user that now() instead of now as a field's default value is probably not what they want.

[AeroNotix]

@mamun patch incoming?

[Markus Holtermann]

Here's the pull request: ​https://github.com/django/django/pull/2346

[Markus Holtermann <info@…>]

In 9d8c73f6a1c636853a5c5013f21985d702b2301b:

Fixed #21905 -- Add info message if DateField or TimeField use a fixed value

[Florian Apolloner <florian@…>]

In 11932e978f980846d2c3326ff070ece7e65bf75c:

Merge pull request #2346 from Markush2010/ticket21905

Fixed #21905 -- Add info message if DateField or TimeField use a fixed value

[Serge Matveenko]

The implementation contains a bug. Here is the code that probably fixes it ​https://github.com/django/django/pull/6749

[Simon Charette]

Please file a new bug report instead of reopening this old fixed one.

[Chris Jerdonek]

The implementation contains a bug. Here is the code that probably fixes it ​​https://github.com/django/django/pull/6749

FYI, this issue was recently rediscovered and fixed as part of #32966.