Opened 10 years ago

Closed 8 years ago

Last modified 3 years ago

#21905 closed New feature (fixed)

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

Reported by: taishi@… Owned by: Markus Holtermann
Component: Core (Other) Version: 1.7-alpha-1
Severity: Normal Keywords: check nlsprint14
Cc: info@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

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())

Change History (21)

comment:1 by matt@…, 10 years ago

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

comment:2 by Markus Holtermann, 10 years ago

Cc: info@… added

comment:3 by taishi@…, 10 years ago

matt@ comment worked

comment:4 by Markus Holtermann, 10 years ago

Component: MigrationsCore (Other)
Keywords: check added; migrate migrations datetime removed
Owner: set to nobody
Summary: django migrate/makemigrations detects changes when none were madeAdd check for default=now() on Date/Time/DateTimeFields

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.

comment:5 by Marc Tamlyn, 10 years ago

Triage Stage: UnreviewedAccepted

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

comment:6 by matheusrosa, 10 years ago

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.
Unless this field is updated by the user, then use datetime.now.

Last edited 10 years ago by matheusrosa (previous) (diff)

comment:7 by Russell Keith-Magee, 10 years ago

@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.

comment:8 by Russell Keith-Magee, 10 years ago

Easy pickings: set

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

comment:9 by Markus Holtermann, 10 years ago

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

comment:10 by Russell Keith-Magee, 10 years ago

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

comment:11 by rkstapenhurst, 10 years ago

Resolution: duplicate
Status: newclosed

Duplicate of #21638

comment:12 by Markus Holtermann, 10 years ago

Resolution: duplicate
Status: closednew

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.

comment:13 by mamun, 10 years ago

Owner: changed from nobody to mamun
Status: newassigned

comment:14 by AeroNotix, 10 years ago

@mamun patch incoming?

comment:15 by Markus Holtermann, 10 years ago

Keywords: nlsprint14 added
Owner: changed from mamun to Markus Holtermann

comment:16 by Markus Holtermann, 10 years ago

Has patch: set

comment:17 by Markus Holtermann <info@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In 9d8c73f6a1c636853a5c5013f21985d702b2301b:

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

comment:18 by Florian Apolloner <florian@…>, 10 years ago

In 11932e978f980846d2c3326ff070ece7e65bf75c:

Merge pull request #2346 from Markush2010/ticket21905

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

comment:19 by Serge Matveenko, 8 years ago

Resolution: fixed
Status: closednew

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

comment:20 by Simon Charette, 8 years ago

Resolution: fixed
Status: newclosed

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

comment:21 by Chris Jerdonek, 3 years ago

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.

Note: See TracTickets for help on using tickets.
Back to Top