DateField and DateTimeField and auto_now, auto_now_add

[Norjee]

Both have the behaviour that "the current date is always used". For
auto_now, it meas it is impossible to set a custom timestamp. For
auto_now_add it means you first have to create the object, save it,
set custom stamp, save again.

First it is odd that if it is intended for the timestamp to be written
in stone, it can be circumvented for auto_now_add.. But at least the
timestamp can be changed ;)

I fail to see why supplying a custom timestamp to override the auto-
timestamp is not allowed. While moving a site to django i import old
articles, which have both a created and updated date. Using django's
models to populate the db with the older data it is impossible to set
the last updated date (Unless of course I temporary change the model
definition). It's all nice for the timestamp to be updated if no data
is given, but when I explicitly give a timestamp I expect it to be
used. (Also think of the scenario when something with a timestamp is
altered, then again it is undone, I would want to cheat and set the
time back as well)

I would propose to allow for overriding these timestamps. If the
current behaviour is the intended behaviors perhaps one could add the
option to explicitly allow for overriding, auto_* (e.g. add the
argument auto_override for DateFields, which defaults to False, but
when set to true allows for custom timestamps) (And I'd gladly add a
patch for it)

[Honza Král]

On 3/13/07, Norjee <Nor...@gmail.com> wrote:
>
> Both have the behaviour that "the current date is always used". For
> auto_now, it meas it is impossible to set a custom timestamp. For
> auto_now_add it means you first have to create the object, save it,
> set custom stamp, save again.
>
> First it is odd that if it is intended for the timestamp to be written
> in stone, it can be circumvented for auto_now_add.. But at least the
> timestamp can be changed ;)
>
> I fail to see why supplying a custom timestamp to override the auto-
> timestamp is not allowed. While moving a site to django i import old
> articles, which have both a created and updated date. Using django's
> models to populate the db with the older data it is impossible to set
> the last updated date (Unless of course I temporary change the model
> definition). It's all nice for the timestamp to be updated if no data
> is given, but when I explicitly give a timestamp I expect it to be
> used. (Also think of the scenario when something with a timestamp is
> altered, then again it is undone, I would want to cheat and set the
> time back as well)

for this use DateField( default=models.LazyDate() ), it will do
exactly what you want: supply a default value of NOW() when no
timestamp is given.

It seems redundant to replicate this with the auto_* stuff, those are
meant to be unchangeable...

>
> I would propose to allow for overriding these timestamps. If the
> current behaviour is the intended behaviors perhaps one could add the
> option to explicitly allow for overriding, auto_* (e.g. add the
> argument auto_override for DateFields, which defaults to False, but
> when set to true allows for custom timestamps) (And I'd gladly add a
> patch for it)
>
>
> >
>

--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585

[Norjee]

> On 14 mrt, 01:40, "Honza Kr=E1l" <honza.k...@gmail.com> wrote:
>
> for this use DateField( default=3Dmodels.LazyDate() ), it will do

> exactly what you want: supply a default value of NOW() when no
> timestamp is given.
>
> It seems redundant to replicate this with the auto_* stuff, those are
> meant to be unchangeable...

I wasn't aware of lazyDate. But unless I'm mistaken isn''t what you
are doing just supplying the current date as default value? This does
solve the issue. As the resulting behaviour is "If no value in db, set
current date, else db value" while I want "If value in db not
explicitly updated, set current date, else supplied date". Neither can
lazy date be forced to be used only at creation time and not at update
time.

Anyway, I'm working on my field that behaves as I expect it would. (it
proves to be a bit of a hassle, as I don't know a way to see where a
value from an existing object (thus via klass.objects.get() comes
from, is it the value in the db, or has it been altered)