On Wed, Nov 25, 2009 at 12:10 AM, jedie <google.gro...@jensdiemer.de> wrote:
> DateTimeField "auto_now" and "auto_now_add" used datetime.now(). But
> why this? IMHO it's better to use datetime.utcnow(), isn't it?
Why would it be? A datetime field isn't necessarily stored in UTC. It
uses datetime.now() because that will return the same time as
settings.TIME_ZONE.
On top of that, making this change would be a *huge* backwards
incompatibility, as any existing uses of auto_now etc would break.
Time zone handling is definitely something that Django could handle
better, but simply switching to UTC for certain functions isn't the
solution.
On 25 Nov., 00:36, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> Why would it be? A datetime field isn't necessarily stored in UTC. It
> uses datetime.now() because that will return the same time as
> settings.TIME_ZONE.
To improve my understanding: What if the server changed and the time
zone is not the same? IMHO the user can choose: 1. leave the
settings.TIME_ZONE to the old value, so all old datetimes are right,
but new datetimes are wrong. Or 2. he can update settings.TIME_ZONE
and old datetimes would be wrong, but new are right. Isn't it?
> On top of that, making this change would be a *huge* backwards
> incompatibility, as any existing uses of auto_now etc would break.
Yes. But it's easy to add a settings and the admin can choose between
now or utcnow. The default settings should be set utcnow.
> Time zone handling is definitely something that Django could handle
> better, but simply switching to UTC for certain functions isn't the
> solution.
Basically, it proposes that timezones are handled analogous to how
Unicode is handled -- that is, everything within Django boundaries is
treated as UTC, with timezone conversions happening on input and
output, but never within Django and always stored as UTC in the
database.
Ticket 10587 was closed as a duplicate of 2626, but I think 10587 has
the better description and proposal in it.
On Wed, Nov 25, 2009 at 7:10 PM, jedie <google.gro...@jensdiemer.de> wrote:
> On 25 Nov., 00:36, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
>> Why would it be? A datetime field isn't necessarily stored in UTC. It
>> uses datetime.now() because that will return the same time as
>> settings.TIME_ZONE.
> To improve my understanding: What if the server changed and the time
> zone is not the same? IMHO the user can choose: 1. leave the
> settings.TIME_ZONE to the old value, so all old datetimes are right,
> but new datetimes are wrong. Or 2. he can update settings.TIME_ZONE
> and old datetimes would be wrong, but new are right. Isn't it?
If the server changes, then it's up to the admin to manage that
change. Django *won't* make a change that will silently destroy the
integrity of existing databases in the field just by updating code,
which is *exactly* what changing to utcnow would do. Right now, there
are *thousands* of Django installations in the field - including many
of my own - that rely on the fact that auto_now uses datetime.now()
and returns a time localized to TIME_ZONE.
This behavior may be flawed, but it doesn't change the fact that this
is the way it currently is.
Storing datetimes in UTC may be a better default strategy, but that
doesn't change the way it currently is.
I am in complete agreement that Django should have better support for
time zones. As Rob Hudson pointed out, there is a long-standing ticket
requesting this (#2626). Changing the behavior of auto_now to return
utcnow doesn't address the larger problem.
>> On top of that, making this change would be a *huge* backwards
>> incompatibility, as any existing uses of auto_now etc would break.
> Yes. But it's easy to add a settings and the admin can choose between
> now or utcnow. The default settings should be set utcnow.
No, on two counts.
1. Adding a setting to fix a problem doesn't fix a problem. It adds a
new problem.
2. The existing value is datetime.now. *If* we were to add such a
setting (and let me tell you right now - we aren't going to), the
default value *must* be to use datetime.now - otherwise you don't get
backwards compatibility by default.
> Basically, it proposes that timezones are handled analogous to how > Unicode is handled -- that is, everything within Django boundaries is > treated as UTC, with timezone conversions happening on input and > output, but never within Django and always stored as UTC in the > database.
I'm +1 on this idealistic solution.
But what about the backwards compatibility for already persisted dates in a timezone different from UTC?
