ANN: Django sprint in Berlin, September 9th, 2011

[Jannis Leidel]

Hi all,

To complement next week's sprint at DjangoCon US in Portland,
I'd like to announce a local sprint happening in Berlin, Germany:

  https://code.djangoproject.com/wiki/Sprint2011Berlin

When: Friday, September 9, 2011, 9am - 10pm

Where:

Jonas und der Wolf GbR
Manteuffelstraße 40
10997 Berlin, Germany

Close to U Görlitzer Bahnhof, map: http://g.co/maps/d2sb
The office is in the backyard building on the second floor.

Please don't forget to RSVP the sprint in Berlin:

  http://www.doodle.com/evbd66ny4pup4uey

For more general information about Django sprints,
please see our wiki page at:

  https://code.djangoproject.com/wiki/Sprints


See you there,

Jannis

-- 
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: class based views: object instead of dictionary as context?

[Luke Plant]

On 01/09/11 21:46, Reinout van Rees wrote:

> Passing the view object to the template by default seems to me to be an
> absolute no-brainer. Class based views ought to mean you get the view
> object in your template, right? But Django doesn't do it. So... is there
> a specific reason for it?

Like Russell, I'd never thought of this idea before. The main argument I
can think of against doing this is that it encodes an implementation
detail into your templates. A template shouldn't know whether the data
has come from a CBV or function, and shouldn't have to be changed if you
go from one to the other or back again (both transitions being sensible
in some circumstances). To me, this change would produce very strong
coupling between the presentation logic and the view that produced it.

The history of CBVs in Django is that they are simply a way of using OOP
and inheritance to reduce duplication between view functions and allow
better re-use. They are supposed to be drop in replacements for function
based views in terms of the end result, rather than produce any change
in what a template will contain. This means that CBVs and function based
views are both first class citizens in Django world, and I for one
prefer it that way.

Slight digression: I do not think that CBVs are obvious winners for
writing views. There are significant trade-offs and downsides, such as
ravioli code, as I've blogged about before [1]. I've recently written an
app from scratch using CBVs heavily, and it worked well, but 1) there
were still times that functions were better, 2) there were some
inheritance problems that required a small amount of fairly heavy-duty
metaclass hackery to solve, 3) the code is less transparent to a newcomer.

Regards,

Luke

[1] http://lukeplant.me.uk/blog/posts/class-based-views-and-dry-ravioli/


-- 
"Doubt: In the battle between you and the world, bet on the world."
(despair.com)

Luke Plant || http://lukeplant.me.uk/

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

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

Regards,

Luke

-- 
"Doubt: In the battle between you and the world, bet on the world."
(despair.com)

Luke Plant || http://lukeplant.me.uk/

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

Multiple timezone support for datetime representation

[Aymeric Augustin]

Hello,

The GSoC proposal "Multiple timezone support for datetime representation" 
wasn't picked up in 2011 and 2010. Although I'm not a student and the summer is 
over, I'd like to tackle this problem, and I would appreciate it very much if a 
core developer accepted to mentor me during this work, GSoC-style.

Here is my proposal, following the GSoC guidelines. I apologize for the wall of 
text; this has been discussed many times in the past 4 years and I've tried to 
address as many concerns and objections as possible.

Definition of success
-

The goal is to resolve ticket #2626 in Django 1.4 or 1.5 (depending on when 1.4 
is released).

Design specification


Some background on timezones in Django and Python
.

Currently, Django stores datetime objects in local time in the database, local 
time being defined by the TIME_ZONE setting. It retrieves them as naive 
datetime objects. As a consequence, developers work with naive datetime objects 
in local time.

This approach sort of works when all the users are in the same timezone and 
don't care about data loss (inconsistencies) when DST kicks in or out. 
Unfortunately, these assumptions aren't true for many Django projects: for 
instance, one may want to log sessions (login/logout) for security purposes: 
that's a 24/7 flow of important data. Read tickets #2626 and #10587 for more 
details.

Python's standard library provides limited support for timezones, but this gap 
is filled by pytz . If you aren't familiar with 
the topic, strongly recommend reading this page before my proposal. It explains 
the problems of working in local time and the limitations of Python's APIs. It 
has a lot of examples, too.

Django should use timezone-aware UTC datetimes internally
.

Example : datetime.datetime(2011, 09, 23, 8, 34, 12, tzinfo=pytz.utc)

In my opinion, the problem of local time is strikingly similar to the problem 
character encodings. Django uses only unicode internally and converts at the 
borders (HTTP requests/responses and database). I propose a similar solution: 
Django should always use UTC internally, and conversion should happen at the 
borders, i.e. when rendering the templates and processing POST data (in form 
fields/widgets). I'll discuss the database in the next section.

Quoting pytz' docs: "The preferred way of dealing with times is to always work 
in UTC, converting to localtime only when generating output to be read by 
humans." I think we can trust pytz' developers on this topic.

Note that a timezone-aware UTC datetime is different from a naive datetime. If 
we were using naive datetimes, and assuming we're using pytz, a developer could 
write:

mytimezone.localize(datetime_django_gave_me)

which is incorrect, because it will interpret the naive datetime as local time 
in "mytimezone". With timezone-aware UTC datetime, this kind of errors can't 
happen, and the equivalent code is:

datetime_django_gave_me.astimezone(mytimezone)

Django should store datetimes in UTC in the database


This horse has been beaten to death on this mailing-list so many times that 
I'll  keep the argumentation short. If Django handles everything as UTC 
internally, it isn't useful to convert to anything else for storage, and 
re-convert to UTC at retrieval.

In order to make the database portable and interoperable:
- in databases that support timezones (at least PostgreSQL), the timezone 
should be set to UTC, so that the data is unambiguous;
- in databases that don't (at least SQLite), storing data in UTC is the 
most reasonable choice: if there's a "default timezone", that's UTC.

I don't intend to change the storage format of datetimes. It has been proposed 
on this mailing-list to store datetimes with original timezone information. 
However, I suspect that in many cases, datetimes don't have a significant 
"original timezone" by themselves. Furthermore, there are many different ways 
to implemented this outside of Django's core. One is to store a local date + a 
local time + a place or timezone + is_dst flag and skip datetime entirely. 
Another is to store an UTC datetime + a place or timezone. In the end, since 
there's no obvious and consensual way to implement this idea, I've chosen to 
exclude it from my proposal. See the "Timezone-aware storage of DateTime" 
thread on this mailing list for a long and non-conclusive discussion of this 
idea.

I'm expecting to take some flak because of this choice :) Indeed, if you're 
writing a multi-timezone calendaring application, my work isn't going to 
resolve all your problems — but it won't hurt either. It may even provide a 
saner foundation to build upon. Once again, there's more than one way to solve 
this problem, and I'm afraid that choosing one would offend some people 
sufficie

Re: Multiple timezone support for datetime representation

[Paul McMillan]

Hi Aymeric,

First, thanks for all your triage work on track, it's very much
appreciated. This is a large proposal, but I think it covers the issue
pretty completely.

I agree with your approach of using UTC internally and converting on output.

My main concern with your proposal is that it may require two
different code paths for a lot of code. I have no objection to the
dependency on pytz, but I don't want this to result in pytz-aware code
that diverges significantly from the non-pytz default path.

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.

This isn't my area of expertise, so I'm not a good mentor candidate,
but I'd be excited to help you with this project where I can.

I'm wholeheartedly +1 on this.

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

[Anssi Kääriäinen]

On Sep 3, 9:19 pm, Paul McMillan  wrote:
> Hi Aymeric,
>
> First, thanks for all your triage work on track, it's very much
> appreciated. This is a large proposal, but I think it covers the issue
> pretty completely.
>
> I agree with your approach of using UTC internally and converting on output.
>
> My main concern with your proposal is that it may require two
> different code paths for a lot of code. I have no objection to the
> dependency on pytz, but I don't want this to result in pytz-aware code
> that diverges significantly from the non-pytz default path.
>
> 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.
>
> This isn't my area of expertise, so I'm not a good mentor candidate,
> but I'd be excited to help you with this project where I can.
>
> I'm wholeheartedly +1 on this.

I'm +1 also.

Some notes:

  - 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. I suggest making a few
testcases upfront For example one could be a fetch of 1 objects
from the DB. Another one is to then render the 1 objects. The last
one is quite slow already if USE_L10N is True, so there is hope this
could actually improve that case.

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

  - 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. I do
not want this information to change if there is a DST change. In the
proposal you are saying that you are not going to tackle this problem.
However, 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. The
user is then free to interpret if it means 08:00 in Helsinki/Europe
timezone, or something else. Storing in UTC does not allow for this
because of DST changes. I guess I am saying that having a
models.DatetimeField(plain=True) would be a good thing...

  - The default for USE_TZ should be False if not specified but True
for new projects. That is, it is included in the settings template as
True but it is False in the global_settings.py.

The design looks good. I am very interested in this. One more piece in
making Django more useful in the enterprise setting. I hope you find
somebody qualified to mentor your project.

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

[Mikhail Korobov]

Great job on summarizing the issue!

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

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.

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? 

-- 
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/-/3sUDTbi24PgJ.
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.