Re: Datetimes with timezones for mysql

[Russell Keith-Magee]

On Tue, Aug 17, 2010 at 12:13 AM, Vitaly Babiy  wrote:
> Hey,
> I been doing a lot with timezone aware dates and I noticed that the mysql
> store will not allow you to store a datetime aware datetime. I was wondering
> if there is a reason why not convert theses dates to whatever is in the
> settings using astimezone. And then save that date.

A good reason? No. :-)

The practical reason is that the current implementation is old and
naive. Django's date/datetime/time fields were added very early in the
life of Django, so the current implementation is essentially the
simplest implementation that could possibly work at the time -- which
means no fancy handling when it comes to timezones.

Adding timezone sensitivity to Django's time/datetime fields is
something that has been on the project to-do list for almost as long
as I've been associated with the project (coming up on 5 years). If
you're interested in tackling this problem, here's a couple of things
to keep in mind:

 * Backwards compatibility. Suddenly introducing a 'convert to local
timezone' behavior (or similar) will break any existing install.
 * The interaction between application timezone and database server timezone.
 * MySQL. Postgres supports timezones in date fields. MySQL doesn't.
We need to have a solid answer for how this feature will work on
databases that don't support timezone handling.

Also worth noting: by strange coincidence, you're the second person in
24 hours that has asked this question; FunkyBob was asking about
timezone support on IRC. This is something I'd love to see addressed;
if there are a couple of motivated people interested in the problem,
it may help to team up to solve it.

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

Datetimes with timezones for mysql

[Vitaly Babiy]

Hey,
I been doing a lot with timezone aware dates and I noticed that the mysql
store will not allow you to store a datetime aware datetime. I was wondering
if there is a reason why not convert theses dates to whatever is in the
settings using astimezone. And then save that date.

Vitaly Babiy

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #11834: colorized debug page. Assigned to buriy

[burc...@gmail.com]

Hi Thomas,

On Mon, Aug 16, 2010 at 8:12 PM, Thomas Guettler  wrote:
> Hi buriy,
>
> http://code.djangoproject.com/ticket/11834
>
> it would be nice, if the CSS could be customized. But how
> to do that?
>
> I think the debug html output should be self contained.
> It should not reference a CSS file. Example: I send the
> HTML output by mail to myself, to see if uncaught exceptions have
> happened on production sites.
>
> Maybe a new (optional) setting: DEBUG_PAGE_CSS_INCLUDE='/pathto/myfile.css'
>
> After we created a patch with configurable CSS, we could make a small
> contest, and the best gets commited to be the default.

Yes, thanks, I though of anything similar.
But don't you think developers should spend time to work on the
project, not make the debug page better?
So here one-size-fits-all solution is much better rather than
customization playground.
The only reason I'm working on this patch is that without colors it's
taking some time to understand what module caused the error if
traceback contains database access, querysets manipulations or
templates processing.
However, you can edit django http500 template and create your own
version, make a good screenshot and impress us.
Just replace default 500 debug response with yours!

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #717 (If-Modified-Since checked for exact match) should be fixed

[julianb]

I just discovered that the condition decorator does check for exact
match only, too. Thus, the ticket should be changed to also include
this issue. Is someone going to reopen the ticket?

On Aug 9, 11:46 pm, Łukasz Rekucki  wrote:
> On 9 August 2010 22:48, Paul McMillan  wrote:> I agree with 
> the person who closed the ticket again, since this should
> > have been discussed on the mailing list prior to re-opening it.
>
> That would be me ;)
>
>
>
> > That said, I'm strongly +1 on this issue. I've had to write
> > workarounds for exactly the described behavior on other systems, and
> > it hasn't been good. Django should follow the RFC and do the sane,
> > rational thing. There are a myriad of use cases these days for
> > retreiving an object without storing the precise previous retrieval
> > time.
>
> The "follow RFC" argument is not that strong. It actually advises
> clients to use the exact date string that was previously returned by
> server if possible. It also notes a few problems when using arbitrary
> dates. A valid use case is far more convincing. If Google's crawler is
> causing problems, it's probably worth fixing.
>
> As for the patch, it only parses one of three date formats required by
> the RFC[1]. So if you want to strictly follow the RFC, it must parse
> all three.
>
> Just my 2 cents.
>
> [1]:http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
>
> --
> Lucas Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #11834: colorized debug page. Assigned to buriy

[Thomas Guettler]

Hi buriy,

http://code.djangoproject.com/ticket/11834

it would be nice, if the CSS could be customized. But how
to do that?

I think the debug html output should be self contained.
It should not reference a CSS file. Example: I send the
HTML output by mail to myself, to see if uncaught exceptions have
happened on production sites.

Maybe a new (optional) setting: DEBUG_PAGE_CSS_INCLUDE='/pathto/myfile.css'

After we created a patch with configurable CSS, we could make a small
contest, and the best gets commited to be the default.

  Thomas

burc...@gmail.com wrote:
> Hi,
> 
> On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler  wrote:
...

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + 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-develop...@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: Gentle Nudge on #12398

[Russell Keith-Magee]

On Mon, Aug 16, 2010 at 6:48 PM, burc...@gmail.com  wrote:
> Hi Falridge,
>
> Russell just said in another thread (
> http://http://groups.google.com/group/django-developers/browse_thread/thread/41ef180b93410cd2/cb0510692d8270b5
> ), that you need to put ticket into RFC if you feel the ticket is
> looking good, is working and other prerequisites have been met.

The caveat on that is that you shouldn't be promoting your own
patches. You should only be marking reviewed tickets as RFC. If you
submit a patch, you should set the has patch flag so that others can
know that it needs review.

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

Tickets #13579 and #8291

[Filip Gruszczyński]

Some time ago I have posted patches and tests for two bugs:

http://code.djangoproject.com/ticket/8291
http://code.djangoproject.com/ticket/13579

Could I ask for some opinion on them? Are they enough, or should I
provide something more for this?

-- 
Filip Gruszczyński

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Gentle Nudge on #12398

[faldridge]

Ticket #12398, the addition of a TypedMultipleChoiceField, is in the
'accepted' state with docs and tests.  Is there anyone who could
commit it to trunk?

Thanks, as always, for all the hard work that goes into this great
framework.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Proposal: adding value and display_value to bound fields.

[Anssi Kaariainen]

Hello all,

This proposal is about adding value and display_value properties to
BoundFields (ticket #10427). The value property gives raw data and
display_value gives the value in user friendly format. For example for
CharField, both value and display_value will be just the raw data. But
for MultipleChoiceField, the value will be something like [1, 3, 14],
that is, not very usable to display to users directly. For
MultipleChoiceField The display_value will be the text representing
the choices.

I can think of at least two usage cases which are not easy to do at
the moment. The first is simply displaying the data of a model to
user. Using this feature you could achieve this by creating a
ModelForm with the instance's data and the following template:

{% for field in form.visible_fields %}
{{ field.label }}: {{field.display_value}}
{% endfor  %}

The other usage case is a workflow which contains first a view page
for the form, with an edit link (Or edit -> preview -> save).  This
would be achieved using the display_value in the preview stage.

As far as I know both of those usage cases are cubersome to do at the
moment, especially for ForeignKey and ManyToMany fields.

The current patch for #10427 implements value and display_value
properties for BoundField. The property values gives raw data using
the following rules:

1. If the form has data for this field, use it;
2. if the form has initial data for this field, use it;
3. if the field has initial data, use it; and lastly
4. use the empty string.

The display_value returns value, except for ChoiceField, which returns
the text of the choice.

The display_value property is clearly not sufficient, as it doesn't
handle MultipleChoiceField, formatting dates and it can't handle
custom fields and widgets properly. A good example of custom fields
and widgets that need special handling is django-ajax-selects:
http://code.google.com/p/django-ajax-selects/.

My proposal is to add display_value() method to widgets. That is, each
widget knows how to render it's value in user friendly format. For
most widgets this will just return the value. But some widgets need
special handling (DateInput, SelectMultiple, custom widgets...).

Now, a few questions:

1. Is this needed in core, is there some other functionality providing
this?
2. Is the proposed solution an acceptable way to do this?
3. What should the signature of widgets display_value be? At the
moment it is the same as render's, that is (name, value, attrs=()).
(Added with choices=() for widgets handling choices.)
4. How exactly should the display_value be rendered? One idea is to
always enclose the value in display_value.
SelectMultiple would be rendered: first_val
5. Should it be possible to say to widget that it should use
display_value when rendering? This would be a replacement for
editable=False. In this case the rendering should probably include
hidden input so that when the form is submitted, the displayed value
can be retrieved from the submit.

In my mind leaving #5 for later is a good idea, so that the first
patch would be implementing only one thing. And there are numerous
other extensions to this feature one can think of...

I have a github repository containing a WIP patch for this (http://
github.com/akaariai/django/tree/ticket10427). At the moment it really
isn't ready, but the idea can be seen in code. Implemented tests are
still from the original #10427 patch, so they are not up to date at
the moment. I hope I will get some clarification to the questions, so
that I can implement this feature.

- 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-develop...@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: Checking if my patch would be a useful contribution

[Russell Keith-Magee]

On Sat, Aug 14, 2010 at 6:12 PM, Swizec Teller  wrote:
> Hi all,
>
> brand new django contributor here, been using it so much I reckon it's
> about time I started giving back :)
>
> Anyhow, I'm using Django primarily to develop RESTful API's for web
> services. This of course means a lot of JSON is getting passed around
> in GET/POST requests so I wrote a simple form field JSONField that
> handles json validation and deserialisation because it was getting
> annoying having to do it by hand all the time.
>
> My question is: Is this something that would be useful to upstream?

My immediate reaction is no, because I can't say I've come across many
REST APIs that use JSON submitted in POST data in form-encoded format
(which I presume is the use case here). When I see REST APIs using
JSON, the POST is usually encoded application/json, and the whole
packet is JSON; any 'field-based' logic is handled by top-level keys
in the JSON. Django-piston is an example of a framework that does this
sort of processing.

I would suggest that this may be better suited to a utility library;
if it turns out this utility library gets lots of use, we can consider
it for inclusion in trunk.

> Oh and I also wrote a decorator for validating forms, makes for
> cleaner code than how current examples in the documentation handle
> that. Should I contribute that too?

We're open to any suggestions, but we need to see what's being proposed.

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