I can't see the problem in that article. Also, the datetime objects have changed since then, taking a timezone as optional parameter: http://docs.python.org/library/datetime.html#datetime-objects
I mean we are using date/time already with our pre-save way of doing things, why should auto_add act any different? On Sep 10, 8:24 pm, Nick Lo <ingredients.com...@gmail.com> wrote: > > By the way drossy, I still don't know why it's evil, just that every > > respected Django dev (and BDFLs) were +1 on removing it (very +1). But > > the reasons don't seem consistent. In one case James B. describe's > > some unexplained side effects of using it (which coincide with another > > bloggers findings) which would make the two attributes unstable. I > > don't know if that is just older behavior from previous releases. > > Since auto_now uses datetime.datetime.now() I don't know if it's > tangential or relevant to point to another article that discusses some > unexpected behaviour of datetime. It says "datetime.now() is never to > be used. Always use datetime.utcnow()": > > http://www.enricozini.org/2009/debian/using-python-datetime/ > > I've not investigated this to any degree so I'm just passing it on as > a potentially relevant sidenote. > > Nick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
