On Feb 20, 11:18 pm, Danny Adair <danny.ad...@unfold.co.nz> wrote:
> On Tue, Feb 21, 2012 at 09:29, Anssi Kääriäinen <anssi.kaariai...@thl.fi>
> wrote:
> >[...]
> >> This is by design. Timezones don't make sense for date or times, only for
> >> datetimes.
>
> > In [15]: activate('Australia/Sydney')
> > In [16]: localtime(now()).date()
> > Out[16]: datetime.date(2012, 2, 21)
> > In [17]: activate('Europe/Helsinki')
> > In [18]: localtime(now()).date()
> > Out[18]: datetime.date(2012, 2, 20)
>
> > So, the date is affected by the current time zone.
>
> You weren't handling date objects, just asking datetimes for their date.
> As you said, nothing surprising here, but I don't understand how this
> is "dangerous":
The danger is that a naive user will use DateField for last_edited
with auto_now=True. He really doesn't want that. The danger is that
the user might read the current tutorial and get his date handling
wrong. Of course the DateField isn't dangerous when you know what you
are doing. I don't think you can expect that from all the new users.
Current documentation doesn't help here.
> > DateField(auto_now=True) together with USE_TZ, some user will see
> > last_edited either in the future, or in the past.
>
> Timezone-aware that's what I would expect.
> Using your above example, if I'm in Sydney saving a model instance,
> the date will be 21 Feb. No timezone in it.
> What else would you want to express with "auto_now" - if you have two
> users in different timezones, whose date is the "authoritative" one?
I am fine with that. UTC date is actually the only way it can work
reasonably, as otherwise comparisons in the DB do not work sanely. The
auto_now code doesn't currently save the date in UTC time, it saves
date as in the user's time zone. The user likely doesn't realize that
using DateField for last edited date isn't wise. He wants
DateTimeField, even if he wants to show just the date part of it. That
works as expected, but Django's documentation doesn't currently
mention anything about that, at least not in DateField documentation.
Another danger is that in current Django trunk datetime.date.today()
doesn't return the UTC date, it returns the date in servers time zone
which is not UTC. This causes problems when comparing dates. This is
done in the tutorial which isn't updated to reflect the default USE_TZ
= True setting.
I feel pretty strongly that if USE_TZ = True, then the process' time
zone should be set to UTC. No expections. I don't think that is done
currently.
There are just too many items to polish if 1.4 is going to be released
anytime soon.
- Anssi
--
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.
