On Feb 20, 8:57 pm, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> On 20 févr. 2012, at 19:52, Yo-Yo Ma wrote:
>
> > On a related note, the new timezone.now() functionality is used for
> > ``DateTimeField.pre_save`` when ``auto_now=True``, but it isn't used
> > for ``DateField.pre_save`` or ``TimeField.pre_save``. Is this a bug I
> > should report, or is there something I'm missing (I'm pretty
> > uninformed when it comes to UTC and timezone related stuff in Python)?
>
> Hello,
>
> 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. There isn't
anything surprising here, of course. However, this makes DateField
really dangerous to use in USE_TZ setting. See below for examples.
Note that whatever you do, if you are using last_edited =
DateField(auto_now=True) together with USE_TZ, some user will see
last_edited either in the future, or in the past. Generally, even if
you want just the date for edit time, you want to use DateTimeField
and show the date in user's current time zone for correct behavior.
Maybe worth a mention in the model field documentation? "Dont use
DateFields when using use_tz=True (except when you know what you are
doing)" would be the short form of it. The long form might give the
last_edited date as one example, maybe poll closing date as another
example. Poll closing date of course doesn't make sense in USE_TZ
setting.
Another question I have meant to ask is if 1.4 is too early to have
USE_TZ = True as default setting? I am afraid there are still some
bugs to iron out, some documentation to improve, helper functions to
add and most of all the timezone handling might confuse new users.
Don't get me wrong: the feature is important and I like it. I just
wonder if the feature is polished enough at the moment. I think it was
actually me who gave the "include it on by default on settings
template" idea. So, I am not opposing that, just wondering if 1.4 is
too early.
An example from the tutorial, part 1:
def was_published_today(self):
return self.pub_date.date() == datetime.date.today()
This returns if the pub_date's date in UTC is the same date as today
in server's current time zone. This is not what the user wants. There
is no mention of USE_TZ in the tutorial. The server's time zone should
be set to UTC when USE_TZ is True. That would make
datetime.date.today() a lot safer, as it would compare correctly to
the UTC dates.
- 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.
