Re: Multiple timezone support for datetime representation

[Aymeric Augustin]

2011/9/6 Paul McMillan :
>> I'm going to use the same trick used by USE_L10N and explained by Anssi: set 
>> USE_TZ to False in global_settings.py and to True in the template of 
>> settings.py. This preserves backwards compatibility but the new code is the 
>> default for new projects.
>
> This isn't gonna work because your new code will have a hard dependency on 
> pytz.

Django uses PIL for ImageField, but it isn't a hard dependency because
it's only imported within functions that actually use it. We can do
the same for pytz if it's only used in a few places.

If a module uses pytz in many functions, I suggest this pattern:

from django.conf import settings
if settings.USE_TZ:
import pytz

And it's a bug to hit code that depends on pytz when USE_TZ is False.

If we want to make some functions (like timezone conversion helpers)
available to anyone who has pytz, regardless of the value of USE_TZ,
we could use this pattern:

try:
import pytz
except ImportError:
if settings.USE_TZ:
raise

-- 
Aymeric Augustin.

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

PHP-inspired user-friendly in-browser DJango install

[Alec Taylor]

Good morning,

I have been using Drupal for a while now, but am slowly moving toward
DJango.

I am currently working on quite an ambitious project, which I will be
releasing under a permissive license (New BSD or better).

I would like my project to be as accessible as possible. To this end,
I would like people without any Python or DJango knowledge to be able
to quickly setup my project.

Here is the web-interface functionality I would like to present to the
user:









[Install]

Can DJango be made do work this way? — If so, do you have some example
code or an existing project which does this?

Thanks for all suggestions,

Alec Taylor

-- 
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: CSRF verification failed. Request aborted.

[Kisitu Augustine]

thanx let me check it out

On Tue, Sep 6, 2011 at 5:43 PM, Silvan Spross  wrote:

> i think this will help:
>
> https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-to-use-it
> *
>  *
>
> *allink.*creative
>
> Die interdisziplinäre und
> marktnahe Designagentur.
> * *
> *
> *
> Silvan Spross
> Leiter Informatik / Partner
> +41 43 333 30 94
> * *
> *
> *
> allink GmbH
> Grubenstrasse 9
> 8045 Zürich
> * *
> *
> *
> *
> **allink.ch*
> * *
> *
> *
>
>
>
> On 06.09.2011, at 14:38, austiine wrote:
>
> wassup people, am learning django by doing a small app but my form
> gives this error "CSRF verification failed. Request aborted." when i
> click the submit button. i've to read about CSRF but i dont it get
> quite clearly. please help
>
> --
> 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.
>
>
>  --
> 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.
>

-- 
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: Multiple timezone support for datetime representation

[Daniel Swarbrick]

On Sep 6, 10:47 pm, Aymeric Augustin
 wrote:

> Under PostgreSQL, I assume I have to use a TIMESTAMP WITH TIME ZONE and set 
> the connection's timezone to UTC if I want non-Django applications using the 
> same database to obtain correct results, regardless of their connection's 
> timezone. To be honest, this is pure speculation; I must check this for each 
> database engine.

Django defaults to "timestamp with time zone" for DateTimeFields on
Postgres. Django also explicitly sets the client connection timezone
to that specified in settings.py, however normal behaviour for a
Postgres client is to inherit the TZ of the host that the client is
running on. Naive timestamps (eg. without timezone) in an INSERT are
assumed to be of the client connection timezone.

SELECTs of "timestamp with time zone" output the UTC offset, for
example, immediately after connecting, and without manually specifying
the TZ, psql inherits my host's TZ (Europe/Berlin):

talk2=> select id, last_login, date_joined from auth_user where id=1;
 id |  last_login   |  date_joined
+---+
  1 | 2011-09-05 18:43:38.050294+02 | 2008-05-03 02:29:14+02

I can change to another TZ easily:

talk2=> set timezone to 'America/Chicago';
SET
talk2=> select id, last_login, date_joined from auth_user where id=1;
 id |  last_login   |  date_joined
+---+
  1 | 2011-09-05 11:43:38.050294-05 | 2008-05-02 19:29:14-05

Notice the timestamps are different, and have a -05 UTC offset now
instead of a +02.

So if you want non-Django applications to use the DB, you just need
the application to be aware of the UTC offset included in the output,
and apply that accordingly. Or if you prefer, you can indeed just set
the client connect TZ to UTC:

talk2=> set timezone to UTC;
SET
talk2=> select id, last_login, date_joined from auth_user where id=1;
 id |  last_login   |  date_joined
+---+
  1 | 2011-09-05 16:43:38.050294+00 | 2008-05-03 00:29:14+00

The main point is that whilst the internal storage of timestamps in
Postgres is UTC Julian dates, the output is always rendered as
localtime for the client connection TZ, whatever that may be.

-- 
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: PHP-inspired user-friendly in-browser DJango install

[Cal Leeming [Simplicity Media Ltd]]

On Tue, Sep 6, 2011 at 6:29 PM, Alec Taylor  wrote:

> Good morning,
>
> I have been using Drupal for a while now, but am slowly moving toward
> DJango.
>
> I am currently working on quite an ambitious project, which I will be
> releasing under a permissive license (New BSD or better).
>
> I would like my project to be as accessible as possible. To this end,
> I would like people without any Python or DJango knowledge to be able
> to quickly setup my project.
>

Uh.. what? Django != Drupal.

Can you please explain a bit more about what you want the end result to be.

Thanks


>
> Here is the web-interface functionality I would like to present to the
> user:
>
> 
>
> 
> 
> 
> 
> 
> 
> [Install]
>
> Can DJango be made do work this way? — If so, do you have some example
> code or an existing project which does this?
>
> Thanks for all suggestions,
>
> Alec Taylor
>
> --
> 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.
>
>

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

Possible documentation (or code) bug related to DEBUG+INTERNAL_IPS

[Cal Leeming [Simplicity Media Ltd]]

Hi,

Documentation states that IPs within 'INTERNAL_IPS' will:
 - See debug comments, when DEBUG is True.

To my eyes, that means that unless the IP is in there, they won't see the
debug comments/page.

However, the debug page is still shown to the user when DEBUG is on, even if
they are not in the internal_ips.

Either this is a bug in the code (this is bad), or the documentation needs
to be amended to be clearer (unless I have misread / skipped something??).

Cal

-- 
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: PHP-inspired user-friendly in-browser DJango install

[Kayode Odeyemi]

On Wed, Sep 7, 2011 at 7:08 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

>
>
> On Tue, Sep 6, 2011 at 6:29 PM, Alec Taylor wrote:
>
>> Good morning,
>>
>> I have been using Drupal for a while now, but am slowly moving toward
>> DJango.
>>
>> I am currently working on quite an ambitious project, which I will be
>> releasing under a permissive license (New BSD or better).
>>
>> I would like my project to be as accessible as possible. To this end,
>> I would like people without any Python or DJango knowledge to be able
>> to quickly setup my project.
>>
>
> Uh.. what? Django != Drupal.
>
> Can you please explain a bit more about what you want the end result to be.
>
>  Thanks
>
>
>>
>> Here is the web-interface functionality I would like to present to the
>> user:
>>
>> 
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> [Install]
>>
>> Can DJango be made do work this way? — If so, do you have some example
>> code or an existing project which does this?
>>
>> Thanks for all suggestions,
>>
>> Alec Taylor
>>
>
I write Drupal myself. But Python is not Drupal and don't see the
comparison.

Python already has in-built modular system. Building install profiles
wouldn't be necessary
either since you can leverage setup tools.

To write those fancy Drupal style installation hooks, you might want to
leverage writing your own
application hooks.

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



-- 
Odeyemi 'Kayode O.
http://www.sinati.com. t: @charyorde

-- 
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: Multiple timezone support for datetime representation

[kayess]

I just wanted to chime in with a couple of extra notes here. I won't
comment on most of it as I think it's all spot on :)

On Sep 3, 10:40 pm, Aymeric Augustin
 wrote:
> Django should use timezone-aware UTC datetimes internally
> .
>
> Example : datetime.datetime(2011, 09, 23, 8, 34, 12, tzinfo=pytz.utc)

There is also a Django time field. How to handle this is kind of hard
as having a timezone on a time field may not make much sense. At the
moment it is up to application code to combine this with a date in a
sane manner. If Django switches to use UTC internally then this is
going to become harder for many users to do correctly. Maybe some
library functions that will help them to do this will work?

Using UTC internally isn't enough in the way that using Unicode
internally is to mean that application writers can factor out time
handling in global applications. For example, if I have a Django
application that tracks retail sales worldwide then a report of sales
figures for any given day probably needs to use the correct local time
at each store to make sense from a business perspective. Using UTC
internally may however make developers aware that there is an issue
for them address earlier -- a good thing.


The other thing that ought to be thought about with this is the admin
time/date widgets which have the 'now' link. This is always filled in
with the browser's current time which plays havoc when admin is used
by a user in a different time zone to the site's settings. It should
be possible to capture the UTC offset along with the time so that the
correct number of minutes is added/subtracted when the field is
processed by Django. Thankfully daylight savings can be ignored here.

Many browsers will send the local time of the request to the server.
This can be used to guess the correct timezone, but it won't get
things right (there's no way to work out the correct DST setting from
this). If the country can be identified in some way then the two
together should be good for most users. The UTC offset in the request
is all that's needed to get localize any times that are sent back
though as again, daylight savings can be ignored -- so long as we
aren't rash enough to presume that this offset tells us the actual
time zone.

Hope this is useful,


Kirit

-- 
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 1.3 LANGUAGE_CODE problem

[pdeegii]

At first sorry for my English :).

LANGUAGE_CODE setting doesn't work correctly.

When I configured LANGUAGE_CODE="mn", but default language code is
"en".

from django.utils.translation import get_language
print get_language()

>>> en
---
then I tried to configure LANGUAGES setting

LANGUAGES = (
("mn": "Mongolia"),
("en": "English"),
)

but still "en"
-
changed LANGUAGES setting

LANGUAGES = (
("mn": "Mongolia"),
("en-us": "English"),
)

now it is "mn"
---
but want above settings

LANGUAGE_CODE = "mn"
LANGUAGES = (
("mn": "Mongolia"),
("en": "English"),
)

It doesn't work correctly. Is it BUG ? or something else?

I also tried creating "mn", "en" locale.

Hope help me. Thanks.

-- 
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: ticket 13125 is waiting for a design decision for 18 months

[Vladimir Kryachko]

I think it has been done on purpose, and should not be changed.
Because different authentication backends may choose to support
inactive users or not. And the default (ModelBackend) supports
inactive users which is expressed in
ModelBackend.supports_inactive_user = True. So I would suggest you
write a custom decorator.

On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen  wrote:
> I'd like to draw attention to an open ticket which needs a design
> decision.
>
> Description:
> "The login_required decorator is not checking User.is_active, as
> staff_member_required does. If an authenticated user is deactivated
> (via setting is_active to False), the user is still able to browse
> login_required-protected views."
>
> For probably most people, the expected and (most likely) wanted
> behavior would be not to let inactive users have access to
> login_required files.
>
> Wim
>
> --
> 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.
>
>

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