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 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
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 foobar
-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
> .
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 reinst
-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) myus
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_v
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 thi
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,
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&q=csrf+cookie+haineault#b29cd0e17c010f54
In short, the first patch add a bullet point in the CSRF error pa
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 mo
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
-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
> `
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().toda
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 t
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
mechani
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
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]
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 so
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
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/H
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 af
-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 tha
(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, he
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
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'
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
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
>>>
>>> #
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,
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,
30 matches
Mail list logo
