Re: Multiple timezone support for datetime representation

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

-Paul

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

[Aymeric Augustin]

Thanks Paul, Anssi, Mikhail and Daniel for reviewing the proposal!

Here are some answers to your remarks.


On 3 sept. 2011, at 20:19, Paul McMillan wrote:
> My main concern with your proposal is that it may require two
> different code paths for a lot of code.

Currently, my best guess is:
- limited changes in the models layer
- some new code in the forms and template layers (if USE_TZ: …)
- most of the duplication will be in the tests, because I have to test 
everything with and without USE_TZ.

Of course, I can't be sure before actually writing the code :)

> I would like this new code to eventually become the default setting,
> but acknowledge that there doesn't seem to be a good way to do that
> and maintain our current backwards compatibility (and external
> dependency) policy.

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.



On 3 sept. 2011, at 21:19, Anssi Kääriäinen wrote:

>  - Performance: The USE_L10N setting made rendering tables consisting
> of numbers much slower (see #14290 for example). It would be good if
> there wasn't any major regressions due to this.

With USE_TZ, rendering a datetime will be slower because of the conversion to 
local time. I have no idea of the performance of pytz. I'll do some benchmarks.

>  - Concurrency: My quick reading of the documentation of pytz
> suggests that this should not be a problem. But your implementation
> would be thread safe, right? The main problem here is localizing the
> timestamps.

Certainly, the implementation must be thread safe, because requests may run 
concurrently in different threads for users in different timezones. I'm pretty 
sure it will work out of the box, and it will be even more isolated if I can 
avoid setting os.environ['TZ'] and calling time.tzset().

>  - I want to save the following information in the database: The
> meeting starts at 08:00 localtime 2011-09-04. Localtime is based on
> some other information, maybe the location of the meeting room.
> (...) it would be very valuable if there were a way to save just a
> plain datetime information in the database if the user so chooses.

In my opinion, and more importantly in PostgreSQL's implementation, a DateTime 
represents a "point in time", in an absolute sense — ignoring relativistic 
effects :)

For your example, I support Daniel's suggestion: use a DateField and a 
TimeField, plus a way to obtain the time zone (like a foreign key to the 
meeting room). That's exactly the information you said you wanted to store :)

I've hesitated a lot to add a "naive=False/True" keyword argument to 
DateTimeField. Right now, I'm still convinced that mixing naive and aware 
DateTimes in the same application a recipe for disaster and that Django 
shouldn't facilitate it.



On 4 sept. 2011, at 00:48, Mikhail Korobov wrote:

> I have one concern though. Can you please explain why is USE_TZ option better 
> than introducing e.g. UtcDateTimeField?

In short, Django shouldn't provide two different ways to represent a "point in 
time". Quoting the Zen of Python: "There should be one-- and preferably only 
one --obvious way to do it."

> USE_TZ=True will break all existing code (including external apps) which 
> relies on django 1.3 documented DateTimeField behavior, this can be scary and 
> will introduce a lot of "if getattr(settings, USE_TZ, False): #..." 
> statements in external apps for backwards compatibility.

This is an interesting question. For backwards compatibility, if a 
DateTimeField is set to a naive datetime (like datetime.datetime.now()) and 
USE_TZ is True, the value should be interpreted in local time and a warning 
should be raised.

With this rule, I believe that most code should work just fine with or without 
USE_TZ, thanks to duck typing. Basically, what works on a naive datetime also 
works on an aware datetime, including timedelta arithmetic.

Of course, applications dedicated to dealing with timezones may break. If 
you're using one, you should probably stick with USE_TZ = False.

> Good UtcDateTimeField implementation can be released as a separate package 
> (and then eventually included in django itself). This way existing django 
> projects will be able to use it without waiting for a release and backwards 
> compatibility won't be broken. Are there obstacles in django itself that 
> prevent this option?

In short, my proposal can't be implemented outside of core because it requires 
a modification of the template engine.

If it could, I'm sure someone would have done it already — ticket #2626 has 
been open for five years.

In fact, I tried to implement these ideas without modifying Django in my 
current project. The result is way too messy for publication, let alone for 
eventual inclusion in Django. My entry point in the template 

Re: CSRF verification failed. Request aborted.

[Silvan Spross]

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.

Re: CSRF verification failed. Request aborted.

[Karen Tracey]

Please ask questions about using Django on the django-users mailing list.
The topic of this list is the development of Django itself.

Karen

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

CSRF verification failed. Request aborted.

[austiine]

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.

Re: Suppressed template errors in admin

[Jens Diemer]

Am 25.08.2011 06:19, schrieb h3:

But this would have side effects on the non-admin templates too.. so
it's not ideal.

Maybe something like this:

TEMPLATE_STRING_IF_INVALID = {'default: '!! Invalid var !!',
'django.contrib.admin': ''}


I do a hack in my admin.py:
-

# some django admin stuff is broken if TEMPLATE_STRING_IF_INVALID != ""
# http://code.djangoproject.com/ticket/3579
if settings.TEMPLATE_STRING_IF_INVALID != "":
# Patch the render_to_response function ;)
from django.contrib.auth import admin as auth_admin
from django.contrib.admin import options

def patched_render_to_response(*args, **kwargs):
old = settings.TEMPLATE_STRING_IF_INVALID
settings.TEMPLATE_STRING_IF_INVALID = ""
result = render_to_response(*args, **kwargs)
settings.TEMPLATE_STRING_IF_INVALID = old
return result

options.render_to_response = patched_render_to_response
auth_admin.render_to_response = patched_render_to_response
-

So you can use TEMPLATE_STRING_IF_INVALID, but it's excluded from django admin 
;)


--

Mfg.

Jens Diemer



http://www.jensdiemer.de

--
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: Suppressed template errors in admin

[Ole Laursen]

On 6 Sep., 09:17, Thomas Guettler  wrote:
> Ole, can you please set up a a branch at github or bitbucket?

Eh, is that not overkill?

I don't think discussing this is worth anyone's time. No need to
promise anything or elevate this to a Big Decision as long as it's
about trivial non-intrusive fixes.

I'm still hoping someone (Russ?) will just take the patch and apply
it, and I can go back to being the happy camper. :)


Ole

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

.save_m2m() failing with multi-database error

[Ben Standefer]

I think I might have found an issue related 
to https://code.djangoproject.com/ticket/14849.  The last comment says to 
please email the django-dev group if there are any questions about the 
ticket, so here I am.  I've done my best to provide a complete test case.

I have an Event model with property 'times', which is a ManyToManyField to 
an EventTime model.  https://gist.github.com/c7d8319df96f5eb22cf3
I am processing data from a POST request with a ModelForm on Event, with a 
custom field and widget: https://gist.github.com/653adb9b0ecbcc823339  The 
widget takes a few POST fields and generates a set of date ranges as a list 
of tuples [(, ), (, )...].  The to_python() method 
of the custom field takes the date ranges and returns a list of EventTime 
objects.

When I try to .save_m2m() the form (test case 
here: https://gist.github.com/6da4f69ade9bc7dc5b3c) I get...
ValueError: Cannot add "": instance is on 
database "default", value is on database "None"

This looks it might be an issue with the new multi-database stuff.  I could 
also be misunderstanding something, but after scouring the documentation for 
several hours I don't see anything implying that this wouldn't work.  I 
suspect the unusual thing I'm doing is creating instances of a Django model 
within my field's to_python() method.  Most of the existing fields use 
to_python() to cast to datetime or Decimal.  Is it not possible to convert 
value(s) into instances of Django models?

Thanks for your help.

-Ben Standefer

-Ben

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/uVcisHlDAzkJ.
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: Suppressed template errors in admin

[Russell Keith-Magee]

On Tue, Sep 6, 2011 at 3:17 PM, Thomas Guettler  wrote:
>
>
> Am 03.09.2011 16:13, schrieb Luke Plant:
>> On 25/08/11 00:39, Russell Keith-Magee wrote:
>>
>>> On principle, I have no objection to the idea of making the admin
>>> templates more robust in the presence of TEMPLATE_STRING_IF_INVALID;
>>> adding dummy values in the context sounds like a reasonable approach
>>> -- *if* doing this doesn't undermine broader error handling in the
>>> templates.
>>
>> If we call this a bug, and agree to fix it, does it mean that from now
>> on for any changes to the admin template we have to be careful to test
>> with TEMPLATE_STRING_IF_INVALID != '' ?
>>
>> That sounds kind of tedious, and I would be against making a promise
>> never to break this again in the future. If we can fix it now with
>> relatively little incovenience, fine, but I don't want that to turn into
>> a promise.
>
> If the django core makes a promise that 
> TEMPLATE_STRING_IF_INVALID=RaiseMissingVariable() is
> supported in admin (and other contrib apps), I will help to get it done.
>
> Up to now, that's why I don't use the template language in my apps.
>
> Zen of Python: Errors should never pass silently.

This particular argument fails because we're not talking about Python,
here. We're talking about a template language that renders to a public
facing output. Errors on user-facing code isn't cool.

Yours,
Russ Magee %-)

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