Re: Should the settings.py template include USE_TZ = True?

[Anssi Kääriäinen]

On Feb 20, 11:24 pm, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/20/2012 01:59 PM, Aymeric Augustin wrote:
>
> > The main reason for enabling time zone support by default in new
> > projects (through the settings.py template) was to store UTC in the
> > database (on SQLite, MySQL and Oracle; PostgreSQL always does that
> > anyway).
>
> > This decision was certainly skewed by my background in enterprise
> > software, where reliable handling of datetimes is a no brainer. But
> > this isn't the most common use case for Django.
>
> > Python doesn't make it very easy to deal with time zones, so forcing
> > that concept on developers isn't friendly. The "right way" to do
> > things is impractical, and there isn't that much space for
> > improvement.
>
> Can you give more specifics here? Exactly how much harder is it to work
> with USE_TZ = True than USE_TZ = False for a new Django developer,
> presuming they don't really care about timezones at this point and just
> want to do things more or less right so as not to box themselves in a
> corner if they want to add real timezone support in the future?
>
> I guess I think there's some value in setting people on the right path
> earlier rather than later, but it really depends on exactly how much
> harder that path is.

Some information about how hard this is can be gotten by updating the
tutorial part I to correctly use timezone aware datetimes. The
tutorial has actually the two most important problems in it:
  - How do I get a timezone aware datetime? This should be explained
shortly in the tutorial, and link to further documentation.
  - How do I correctly compare dates in timezone aware setting? This
should say that timezone affects what date it is. Here is how you
compare correctly dates in timezone aware way. (The comparison should
be localtime(self.pub_date).date() == localtime(now()).date()). I
think a small warning about DateFields would be good here.

Now, when you get how the timezone system in Django works it isn't
really that hard to do. My point is mainly that the documentation
currently doesn't actually work with USE_TZ = True, and there is some
work in updating it.

 - 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.

Re: Should the settings.py template include USE_TZ = True?

[Aymeric Augustin]

On 20 févr. 2012, at 23:52, Jacob Kaplan-Moss wrote:

> But I do think we should have some help for people transitioning --
> perhaps a timezone FAQ would be in order?

Jacob,

That's a good idea. I've created a ticket: 
https://code.djangoproject.com/ticket/17738

Everyone,

If you think timezones are hard, please post your questions or problems in the 
comments of that ticket, so I can address them in the FAQ.

Thanks!

-- 
Aymeric.

-- 
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.

Re: django-admin.py startproject creating duplicate settings.py files

[Aymeric Augustin]

On 21 févr. 2012, at 04:31, Yo-Yo Ma wrote:

> I have trunk installed from last night, and this is actual terminal
> output (except for the stuff omitted on the left of the $):
> 
> (my_venv) myusername$ django-admin.py startproject foobarz
> (my_venv) myusername$ ls foobarz/
> __init__.py   foobarz manage.py   settings.py urls.py
> (my_venv) myusername$ ls foobarz/foobarz/
> __init__.py   settings.py urls.py wsgi.py
> 
> 
> I opened both settings.py files, and they are indeed identical files.
> Is this intentional? I was interested in the new manage.py format, so
> I thought I'd adjust my app to use it and whatever other new layout
> features, but clearly this isn't correct.

I discussed a similar problem on IRC a few days ago, which turned out to be 
caused by an incorrect installation of Django. The developer installed Django 
by cloning the git mirror and running "setup.py install". This doesn't remove 
obsolete files in the target install location.

See 
https://docs.djangoproject.com/en/dev/topics/install/#installing-the-development-version

If that doesn't explain your problem, you could search your entire system for 
directories called "project_template"; one of them probably contains the broken 
layout you're seeing, and that's the "active" installation of Django.

Installation issues are difficult to debug over email, but I hope this helps.

Best regards,

-- 
Aymeric.

-- 
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.

Re: django-admin.py startproject creating duplicate settings.py files

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 02/20/2012 09:19 PM, Yo-Yo Ma wrote:
> (myvenv)My-Names-MacBook-Pro:dev myusername$ mkdir test_startproject
> (myvenv)My-Names-MacBook-Pro:dev myusername$ cd test_startproject/
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls -a
> . ..
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ django-
> admin.py startproject testing123
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
> testing123
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
> testing123/
> __init__.py   manage.py   settings.py testing123  urls.py
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
> testing123/testing123/
> __init__.py   settings.py urls.py wsgi.py
> (myvenv)My-Names-MacBook-Pro:test_startproject myusername$

Sorry, no idea. You could stick some "pdb.set_trace()" into the copy
function and see where it's getting those files from, I guess.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9DKFYACgkQ8W4rlRKtE2ciuwCg6ofAId96AwlvEkZunujznLiA
eGsAnjWKVXRR4pwPzWRBMPx6M7n3/V1V
=04ia
-END PGP SIGNATURE-

-- 
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.

Re: django-admin.py startproject creating duplicate settings.py files

[Yo-Yo Ma]

Hey Carl,

Thanks for the reply. I removed everything from my venv's site-
packages directory (except PIL and some other graph library), then
checked to make sure I wasn't able to use django-admin.py or my app's
manage.py scripts (ie, making sure there wasn't a global Django
install). I then reinstalled Django after pulling the latest master
from the github mirror, moved to ~/dev and then: (actual copy/paste
from my shell, minus find/replace of my personal/info):

(myvenv)My-Names-MacBook-Pro:dev myusername$ mkdir test_startproject
(myvenv)My-Names-MacBook-Pro:dev myusername$ cd test_startproject/
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls -a
.   ..
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ django-
admin.py startproject testing123
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123/
__init__.py manage.py   settings.py testing123  urls.py
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123/testing123/
__init__.py settings.py urls.py wsgi.py
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$

I'm not pulling your chain. I've never had this happen before, and
Django functions just fine otherwise (except for now issuing a warning
about using naive datetimes in Field.__init__, which is ironically
right up the alley of my other thread)

Note: In site-packages for the venv, I show Django-1.4b1-py2.7.egg-
info


On Feb 20, 8:56 pm, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/20/2012 08:31 PM, Yo-Yo Ma wrote:
>
> > I have trunk installed from last night, and this is actual terminal
> > output (except for the stuff omitted on the left of the $):
>
> > (my_venv) myusername$ django-admin.py startproject foobarz
> > (my_venv) myusername$ ls foobarz/
> > __init__.py        foobarz         manage.py       settings.py     urls.py
> > (my_venv) myusername$ ls foobarz/foobarz/
> > __init__.py        settings.py     urls.py         wsgi.py
>
> > I opened both settings.py files, and they are indeed identical files.
> > Is this intentional? I was interested in the new manage.py format, so
> > I thought I'd adjust my app to use it and whatever other new layout
> > features, but clearly this isn't correct.
>
> Nope, it's not correct, and I can't reproduce it either. I get just a
> "manage.py" in the outer directory, and settings/urls/wsgi in the
> package. My guess is that you already had an old-style startproject in
> that "foobarz" directory or something. Try it again, and make sure the
> target directory doesn't exist. Also try cleaning your Django repo of
> untracked files; it's possible you somehow got extra files in the
> conf/project_template directory that don't belong there?
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9DFf4ACgkQ8W4rlRKtE2cY7QCgvT5GMOuWLAgjl6QI3R/cBd6P
> Py8AoIQaqmi11fOfx67mz+kzl8bi95iv
> =zEND
> -END PGP SIGNATURE-

-- 
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.

django-admin.py startproject creating duplicate settings.py files

[Yo-Yo Ma]

I have trunk installed from last night, and this is actual terminal
output (except for the stuff omitted on the left of the $):

(my_venv) myusername$ django-admin.py startproject foobarz
(my_venv) myusername$ ls foobarz/
__init__.py foobarz manage.py   settings.py urls.py
(my_venv) myusername$ ls foobarz/foobarz/
__init__.py settings.py urls.py wsgi.py


I opened both settings.py files, and they are indeed identical files.
Is this intentional? I was interested in the new manage.py format, so
I thought I'd adjust my app to use it and whatever other new layout
features, but clearly this isn't correct.

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

Thanks, Danny. That's really helpful to me, and I appreciate you
taking the time to explain it.

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Danny Adair]

On Tue, Feb 21, 2012 at 14:17, Yo-Yo Ma  wrote:
>[...]
> When using UTC, which, if any, are true:

Not sure what you mean by "using UTC", I assume you mean "USE_TZ = True".
As per first sentence of
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/
"When support for time zones is enabled, Django stores date and time
information in UTC in the database, uses time zone-aware datetime
objects internally, and translates them to the end user’s time zone in
templates and forms."

> A) If I have a view that simply adds a record of a model with a
> datetime field, and 3 users in different timezones load the view at
> the same time, all 3 records will have the same datetime value
> (assuming, of course, the database was able to write all 3 records
> within the same microsecond)

They will have the same value in the database, yes.

> B) UTC is *the* way to go for almost any application which will have a
> timezone = models.CharField(... setting for each user profile

See above - database will store everything in UTC.
You could use a timezone field like that to store user timezone and
activate it, e.g. through a middleware -
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#selecting-the-current-time-zone

NB: PostgrSQL already stores UTC internally -
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#postgresql
"The PostgreSQL backend stores datetimes as timestamp with time zone.
In practice, this means it converts datetimes from the connection's
time zone to UTC on storage, and from UTC to the connection's time
zone on retrieval."
For other backends that store naive datetimes "in UTC" means "assumed
as being UTC".

> C) When each user has a timezone setting, it doesn't affect the
> datetime that's entered into the database, it just gives me the
> ability to display the time to them in their timezone

It doesn't affect the database.
But it's up to you (middleware) to "activate" their timezone in order
to make it the "current" timezone.
If you don't do that, the "default" timezone (TIME_ZONE setting) will
be the current timezone.
Whatever a user enters in their "current" timezone is converted to UTC
for storage - UTC is the only sane "common denominator".

Cheers,
Danny

-- 
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.

Request for review for a small fix in the csrf view

[h3]

I've submitted a ticket[1] with two patches as a follow-up to this
discussion:

http://groups.google.com/group/django-developers/browse_thread/thread/ca34924871e3c00b/b29cd0e17c010f54?lnk=gst=csrf+cookie+haineault#b29cd0e17c010f54

In short, the first patch add a bullet point in the CSRF error page
which states that this
error can be triggered by disabled cookies.

The second patch fixes the middleware itself to make the page show the
correct error message if the
error is caused by disabled cookies.

The error message was already in the django source code, it was just
not used.

Both are really small patches, but I decided to make two patch to
increase the chances that at least the error
message gets in for 1.4 final (it's only two lines of HTML).

I did not dare to mark it as release blocker, but I do believe it
should be in 1.4..

1. https://code.djangoproject.com/ticket/17732

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

I actually know so little that I was even more confused by my own
question, but I appreciate your reply, Danny. I feel pretty challenged
when I try to understand timezone-related stuff. Is this correct:

When using UTC, which, if any, are true:

A) If I have a view that simply adds a record of a model with a
datetime field, and 3 users in different timezones load the view at
the same time, all 3 records will have the same datetime value
(assuming, of course, the database was able to write all 3 records
within the same microsecond)
B) UTC is *the* way to go for almost any application which will have a
timezone = models.CharField(... setting for each user profile
C) When each user has a timezone setting, it doesn't affect the
datetime that's entered into the database, it just gives me the
ability to display the time to them in their timezone

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Danny Adair]

On Tue, Feb 21, 2012 at 13:17, Yo-Yo Ma  wrote:
> I haven't quite read up on all the UTC-related stuff in Django as of
> yet (couldn't find much info about it), but I found some of the posts
> above concerning. It would seem that if a DateTimeField should be
> updated with ``timezone.now()``, then a DateField should be updated
> with ``timezone.now().today()``, and TimeField should be updated with
> ``timezone.now().time()``, no? If I'm in EST time, and the server is
> in MST, and it's 11:00PM on the server, my records should be updated
> as the following day, since it's 1:00AM EST. Is this naive to assume
> (if not, apologies for my lack of know-how regarding TZ issues)?

There's a logic to either way, but I agree that auto_now for a date
should use the user's timezone to determine "today", not the server's.
It would be very weird for me to add a model instance and be told that
I did that "tomorrow".

Cheers,
Danny

>
> --
> 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.
>



-- 
Kind regards,

Danny W. Adair
Director
Unfold Limited
New Zealand

Talk:       +64 - 9 - 9555 101
Fax:        +64 - 9 - 9555 111
Write:      danny.ad...@unfold.co.nz
Browse:     www.unfold.co.nz
Visit/Post: 253 Paihia Road, RD 2, Kawakawa 0282, New Zealand

"We are what we repeatedly do. Excellence, then, is not an act but a habit."

==
Caution
The contents of this email and any attachments contain information
which is CONFIDENTIAL to the recipient. If you are not the intended
recipient, you must not read, use, distribute, copy or retain this
email or its attachments. If you have received this email in error,
please notify us immediately by return email or collect telephone call
and delete this email.  Thank you.  We do not accept any
responsibility for any changes made to this email or any attachment
after transmission from us.
==

-- 
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.

Re: Re-posting of previous thread: ``QuerySet.update`` not updating ``auto_now=True`` fields

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/20/2012 05:11 PM, Yo-Yo Ma wrote:
> I understand that ``QuerySet.update`` issues an UPDATE SQL statement,
> but Django's code could be modified to include each ``auto_now=True``
> field on a model in the UPDATE statement, setting the value to
> ``datetime.now()`` as it does when you use ``Model.save``.

There is already a ticket for this (#15566).

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9C5YkACgkQ8W4rlRKtE2dlyQCcCXYg8kWqVda8SWDOcehpCNXc
MIUAoIl018Rwf+b0hdxq0YI2uw46vepc
=Njjf
-END PGP SIGNATURE-

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

I haven't quite read up on all the UTC-related stuff in Django as of
yet (couldn't find much info about it), but I found some of the posts
above concerning. It would seem that if a DateTimeField should be
updated with ``timezone.now()``, then a DateField should be updated
with ``timezone.now().today()``, and TimeField should be updated with
``timezone.now().time()``, no? If I'm in EST time, and the server is
in MST, and it's 11:00PM on the server, my records should be updated
as the following day, since it's 1:00AM EST. Is this naive to assume
(if not, apologies for my lack of know-how regarding TZ issues)?

-- 
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.

Re-posting of previous thread: ``QuerySet.update`` not updating ``auto_now=True`` fields

[Yo-Yo Ma]

It seems my previous question was co-opted... by myself, so rather
than try to distract the conversation about TZ stuff (which seems to
be pretty important stuff, esp with the 1.4 launch), I figured I'd
start a new thread with my original question. Here it is:


If you call ``QuerySet.update`` on the following model, you'll get the
results that proceed it:

# models.py
class Person(models.Model):
cool = models.BooleanField(default=False)
updated_on=DateTimeField(auto_now=True)

# django-admin.py shell
>>> from myapp.models import Person

>>> # Check the updated_on values
>>> Person.objects.values_list('updated_on', flat=True)

[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
>>> # Fine, just as they are in the fixture. Update ``cool`` field on them
>>> Person.objects.update(cool=True)
2
>>> # Check the updated_on values again
>>> Person.objects.values_list('updated_on', flat=True)

[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]

I understand that ``QuerySet.update`` issues an UPDATE SQL statement,
but Django's code could be modified to include each ``auto_now=True``
field on a model in the UPDATE statement, setting the value to
``datetime.now()`` as it does when you use ``Model.save``.

If this seems reasonable, I'll be happy to write a patch and tests for
it.

Note: I'm using the latest trunk code (1.4 beta), pulled yesterday

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Danny Adair]

On Tue, Feb 21, 2012 at 10:48, Anssi Kääriäinen  wrote:
>[...]
> Current documentation doesn't help here.

I agree that a "Timezones FAQ" should mention
DateField(auto_now=True), with a reference from there also back to the
FAQ.

Really the complication are the timezones themselves, not the
mechanism handling them. If USE_TZ is True by default, users without
timezone experience should be advised that "today" can also be a
matter of location.

Cheers,
Danny

-- 
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.

Re: Should the settings.py template include USE_TZ = True?

[Jacob Kaplan-Moss]

Donald Stufft wrote:
> I'm very much pro USE_TZ = True being the default.

I very much agree.

I've been bitten by a few "can't use naive datetimes" errors as I've
been upgrading, but these are easy bugs: they show up when running
tests, and are fixed trivially.

On the other hand, the kind of bugs that *not* having good timezone
support causes are *much* more complicated: email notifications going
out at the wrong time, people's credit cards getting billed early or
late or not at all, etc. And don't get me started on calendaring.
Essentially, without timezones any sort of scheduling functionality is a
rats nest of subtle bugs. Adding timezone support exposes these bugs
early, and that's a *good thing*.

I think of it along the lines of Python 3's new Unicode support: it's a
bit of a pain as you learn the new rules, but once you learn them all
those run-time "cannot decode/encode" errors go away. Ditto timezones.

So yeah, USE_TZ=True in the default project template.

But I do think we should have some help for people transitioning --
perhaps a timezone FAQ would be in order?

Jacob

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Anssi Kääriäinen]

On Feb 20, 11:18 pm, Danny Adair  wrote:
> On Tue, Feb 21, 2012 at 09:29, Anssi Kääriäinen  
> 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.

Re: Should the settings.py template include USE_TZ = True?

[Anssi Kääriäinen]

On Feb 20, 10:59 pm, Aymeric Augustin
 wrote:
> (subject changed because I'm forking the discussion)
>
> On 20 févr. 2012, at 21:29, Anssi Kääriäinen wrote:
>
> > 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.
>
> I was thinking about that too.
>
> The main reason for enabling time zone support by default in new projects 
> (through the settings.py template) was to store UTC in the database (on 
> SQLite, MySQL and Oracle; PostgreSQL always does that anyway).
>
> This decision was certainly skewed by my background in enterprise software, 
> where reliable handling of datetimes is a no brainer. But this isn't the most 
> common use case for Django.
>
> Python doesn't make it very easy to deal with time zones, so forcing that 
> concept on developers isn't friendly. The "right way" to do things is 
> impractical, and there isn't that much space for improvement. Besides, the 
> average website doesn't need time zone support, and IRC discussions show that 
> developers don't care.
>
> What do others think?

While I do not fall in the others category...

I quickly grepped the source code for datetime. I think there are at
least 30 lines (out of total 300) in the documentation which use
datetime incorrectly. Likely more. I think the code isn't totally safe
either. I don't think there is any way all of these can be fixed in
time for 1.4. Of course, punting 1.4 further back is another option.
In addition, database aggregation for example seems to be pretty hard
to do correctly (group by date etc).

For 1.5 I suggest a new module is added: django.utils.datetime. If
USE_TZ is True, then it returns all the times (if at all possible) in
UTC-aware datetime (actually datetime subclass instances). These
datetimes would have at least one additional method: .as_localtime().
If USE_TZ is False, it is the same as Python's datetime module (maybe
have localtime even in this case, it just returns self). That would
make fixing the code and documentation much easier, just use from
django.utils import datetime where you had used import datetime
before. Search & Replace mostly. Supporting the module might be a
little annoying, although datetime isn't exactly a fast-moving target
(one "new in version 2.x" for each of 5, 6, 7), and most of the
methods do not need overriding anyways.

 - 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.

Re: Should the settings.py template include USE_TZ = True?

[Donald Stufft]

On Monday, February 20, 2012 at 4:24 PM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 02/20/2012 01:59 PM, Aymeric Augustin wrote:
> > The main reason for enabling time zone support by default in new
> > projects (through the settings.py template) was to store UTC in the
> > database (on SQLite, MySQL and Oracle; PostgreSQL always does that
> > anyway).
> > 
> > This decision was certainly skewed by my background in enterprise
> > software, where reliable handling of datetimes is a no brainer. But
> > this isn't the most common use case for Django.
> > 
> > Python doesn't make it very easy to deal with time zones, so forcing
> > that concept on developers isn't friendly. The "right way" to do
> > things is impractical, and there isn't that much space for
> > improvement.
> > 
> 
> 
> Can you give more specifics here? Exactly how much harder is it to work
> with USE_TZ = True than USE_TZ = False for a new Django developer,
> presuming they don't really care about timezones at this point and just
> want to do things more or less right so as not to box themselves in a
> corner if they want to add real timezone support in the future?
> 
> 

In my experience with using Django 1.4a1, and now 1.4b1 with USE_TZ=True it has 
not been difficult. The biggest hurdle is that when generating
a date/time programmatically you need to make sure to attach a timezone to it. 
With pytz this is pretty easy. ``datetime.datetime().replace()`` 
instead of just ``datetime.datetime()``.

Really the biggest hurdle I had in using 1.4 with USE_TZ = True is that 
libraries I don't control tend to use date/times without a timezone attached 
causing an exception. I would argue that this is a benefit rather than a 
negative though as otherwise you just kind of assume that those other libraries 
are using the same timezone as you (``datetime.datetime.now vs date 
time.datetime.utcnow vs datetime's coming from another source in any other 
timezone``). And I feel like my code has less of a chance for silent data 
corruption now that I am no longer just assuming that libraries are using the 
same timezone as me and I explicitly attach a timezones to the incoming 
date/times asap.
> 
> I guess I think there's some value in setting people on the right path
> earlier rather than later, but it really depends on exactly how much
> harder that path is.
> 
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk9CugQACgkQ8W4rlRKtE2fr6wCg2/cXMn/bHL/p6Cg5YDzZmPNe
> AasAoKWeKEnDnWvcuYZR3EsqRsMlRfnB
> =Sjc9
> -END PGP SIGNATURE-
> 
> -- 
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 
> 


-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Danny Adair]

On Tue, Feb 21, 2012 at 09:29, Anssi Kääriäinen  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":

> 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?

Cheers,
Danny

-- 
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.

Re: Should the settings.py template include USE_TZ = True?

[Donald Stufft]

On Monday, February 20, 2012 at 3:59 PM, Aymeric Augustin wrote:
> (subject changed because I'm forking the discussion)
>  
> On 20 févr. 2012, at 21:29, Anssi Kääriäinen wrote:
>  
> > 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.
> >  
>  
>  
> I was thinking about that too.
>  
> The main reason for enabling time zone support by default in new projects 
> (through the settings.py template) was to store UTC in the database (on 
> SQLite, MySQL and Oracle; PostgreSQL always does that anyway).
>  
> This decision was certainly skewed by my background in enterprise software, 
> where reliable handling of datetimes is a no brainer. But this isn't the most 
> common use case for Django.
>  
> Python doesn't make it very easy to deal with time zones, so forcing that 
> concept on developers isn't friendly. The "right way" to do things is 
> impractical, and there isn't that much space for improvement. Besides, the 
> average website doesn't need time zone support, and IRC discussions show that 
> developers don't care.  
>  
> What do others think?
I'm very much pro USE_TZ = True being the default. (On another note, i'm also 
Pro TIME_ZONE defaulting to UTC). UTC is the only time representation that 
makes sense for long term storage. All of the other timezones all have a long 
list of "gotchas" to dealing with them, especially
in the storage side.
> --  
> Aymeric.
>  
> --  
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>  
>  


-- 
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.

Re: Should the settings.py template include USE_TZ = True?

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/20/2012 01:59 PM, Aymeric Augustin wrote:
> The main reason for enabling time zone support by default in new
> projects (through the settings.py template) was to store UTC in the
> database (on SQLite, MySQL and Oracle; PostgreSQL always does that
> anyway).
> 
> This decision was certainly skewed by my background in enterprise
> software, where reliable handling of datetimes is a no brainer. But
> this isn't the most common use case for Django.
> 
> Python doesn't make it very easy to deal with time zones, so forcing
> that concept on developers isn't friendly. The "right way" to do
> things is impractical, and there isn't that much space for
> improvement.

Can you give more specifics here? Exactly how much harder is it to work
with USE_TZ = True than USE_TZ = False for a new Django developer,
presuming they don't really care about timezones at this point and just
want to do things more or less right so as not to box themselves in a
corner if they want to add real timezone support in the future?

I guess I think there's some value in setting people on the right path
earlier rather than later, but it really depends on exactly how much
harder that path is.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9CugQACgkQ8W4rlRKtE2fr6wCg2/cXMn/bHL/p6Cg5YDzZmPNe
AasAoKWeKEnDnWvcuYZR3EsqRsMlRfnB
=Sjc9
-END PGP SIGNATURE-

-- 
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.

Should the settings.py template include USE_TZ = True?

[Aymeric Augustin]

(subject changed because I'm forking the discussion)

On 20 févr. 2012, at 21:29, Anssi Kääriäinen wrote:

> 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.

I was thinking about that too.

The main reason for enabling time zone support by default in new projects 
(through the settings.py template) was to store UTC in the database (on SQLite, 
MySQL and Oracle; PostgreSQL always does that anyway).

This decision was certainly skewed by my background in enterprise software, 
where reliable handling of datetimes is a no brainer. But this isn't the most 
common use case for Django.

Python doesn't make it very easy to deal with time zones, so forcing that 
concept on developers isn't friendly. The "right way" to do things is 
impractical, and there isn't that much space for improvement. Besides, the 
average website doesn't need time zone support, and IRC discussions show that 
developers don't care. 

What do others think?

-- 
Aymeric.

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Anssi Kääriäinen]

On Feb 20, 8:57 pm, Aymeric Augustin
 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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Aymeric Augustin]

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.

See also 
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#naive-and-aware-datetime-objects

Best regards,

-- 
Aymeric.

-- 
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.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

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)?

-- 
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.

auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

If you call ``QuerySet.update`` on the following model, you'll get the
results that proceed it:

# models.py
class Person(models.Model):
cool = models.BooleanField(default=False)
updated_on=DateTimeField(auto_now=True)


# django-admin.py shell
>>> from myapp.models import Person
>>>
>>> # Check the updated_on values
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
>>> # Fine, just as they are in the fixture. Update ``cool`` field on them
>>> Person.objects.update(cool=True)
2
>>> # Check the updated_on values again
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]


I understand that ``QuerySet.update`` issues an UPDATE SQL statement,
but Django's code could be modified to include each ``auto_now=True``
field on a model in the UPDATE statement, setting the value to
``datetime.now()`` as it does when you use ``Model.save``.

If this seems reasonable, I'll be happy to write a patch and tests for
it.


Note: I'm using the latest trunk code (1.4 beta), pulled yesterday

-- 
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.

Re: auth.User usernames

[Tom Evans]

On Sat, Feb 18, 2012 at 4:25 AM, Tai Lee  wrote:
> It's not that hard to just set up a OneToOneField back to User, and
> use signals to automatically create a User when you create your own
> User/Profile. Then you can still make use of 3rd party apps that rely
> on contrib.auth or contrib.sessions, and also make use of groups from
> contrib.auth, etc.
>
> Cheers.
> Tai.
>

Once you are aware of the issue, it's easier to change the code so
that it DTRT in the first place. Any other solution has notable
downsides, like the username field not being what the user enters to
log in with, the email field not being correct.

Eg, with your fix authenticating/storing longer emails on a
UserProfile object may work, but it's unlikely that third party code
which sends emails will be aware that the correct email address to use
is user.get_profile().real_email_field rather than user.email.

Those sorts of bugs are much harder to find/fix than the actual bugs,
which are that both email and username fields are too short, and the
username field has arbitrary restrictions on what it can contain.

Cheers

Tom

-- 
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.

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

[Anssi Kääriäinen]

On Feb 20, 12:18 am, Yo-Yo Ma  wrote:
> Speaking with regards to the ORM method documented 
> athttps://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-...
>
> Of course, ``prefetch_related`` uses a Pythonic join to attach reverse-
> related objects and avoids the N+1 queries problem, which of course is
> great. However, if you use it like this:
>
> >>> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type')
>
> It doesn't seem to take advantage ``select_related`` (assuming that
> ``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead
> sends a separate query for ``Topping`` and ``ToppingType``, joining
> them in Python. Is it feasible to modify ``prefetch_related`` use
> ``select_related`` when it encounters a ``ForeignKey``?

Basically a good idea. However, the current stage of prefetch_related
development is "wait and see". That is, prefetch_related is new and
there isn't too good knowledge of why and how people will use it. So,
wait a month or two and after 1.4 has been out for a little while
there is much better knowledge of the pain-points.

 - 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.