3

enter image description here

The above is one of my tables in admin interface in the descending order of id(recent record is at top). And here is the way I used to create the model objects and save.

notification = Notification(from_user=from_user, to_user=to_user,
                            created_date=datetime.now())
notification.save()

All the inserts to this table Notification are done only in the various post_save signal handlers. Will it cause any inconsistencies like these?

Using TIME_ZONE = 'GMT' in django 1.3.2. I could try with auto_now_add=True option in the model but before that just want to know why this is happening.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Babu
  • 2,548
  • 3
  • 30
  • 47
  • 3
    `datetime.now()` returns local time, so the only way I can see that this could occur is if different requests have a different local time zone. Is that possible in your app at all? Try `datetime.utcnow()`. It's generally good practice to store dates in UTC anyway. – Austin Phillips Feb 05 '13 at 12:38
  • +1 for utc mentioning. But I believe that the `datetime.now()` returns local time(machine time or the one given in `TIME_ZONE`) rather than the request time zone. So there should be an another way. – Babu Feb 05 '13 at 12:55
  • What platform are you on? Windows per chance? – Austin Phillips Feb 05 '13 at 13:11
  • nope. In Ubuntu linux. – Babu Feb 05 '13 at 13:12

3 Answers3

5

auto_now_add is not a good approach. Avoid to use it. The best way is to use set default value:

from django.utils import timezone

date_created = models.DateTimeField(default=timezone.now)

django.utils.timezone will store the datetime according to your timezone settings.

Notice the missing () after timezone.now that is because we are passing a callable to the model and it will be called each time a new instance is saved. With the parentheses, it's only being called once when models.py loads. This question clarifies this issue in more details.

Community
  • 1
  • 1
Aamir Rind
  • 38,793
  • 23
  • 126
  • 164
  • 6
    Why is `auto_now_add` not a good approach and should it be avoided? – Bouke Feb 05 '13 at 12:45
  • 1
    Yes, I also would like to know. – Babu Feb 05 '13 at 12:56
  • 1
    There is a lot of discussion in past about auto_now and auto_now_add. I will give some reference links here see [this](http://stackoverflow.com/questions/1737017/django-auto-now-and-auto-now-add) and [this](http://stackoverflow.com/questions/10195020/why-django-lint-tells-me-the-auto-now-add-is-deprecated) – Aamir Rind Feb 05 '13 at 13:09
2

You should not initialize the datetime.now() while defining the model. This causes some kind of "caching" the datetime.now.

Instead of:

Notification(from_user=from_user, to_user=to_user,
                            created_date=datetime.now())

You should use:

Notification(from_user=from_user, to_user=to_user,
                            created_date=datetime.now)
Josh Crozier
  • 233,099
  • 56
  • 391
  • 304
Yiğit Güler
  • 1,150
  • 10
  • 11
1

I believe it's due to the way Pythons runtime environment processes, hopefully someone can re-iterate on that. auto_add_now=True should be the solution as you've suggested.

  • Could you please post anything in detail regarding the `runtime environment process`? – Babu Feb 05 '13 at 12:36