Re: Datetimes with timezones for mysql
On Tue, Aug 17, 2010 at 12:13 AM, Vitaly Babiywrote: > 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
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
Hi Thomas, On Mon, Aug 16, 2010 at 8:12 PM, Thomas Guettlerwrote: > 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
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 Rekuckiwrote: > 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
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 Guettlerwrote: ... -- 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
On Mon, Aug 16, 2010 at 6:48 PM, burc...@gmail.comwrote: > 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
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
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.
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
On Sat, Aug 14, 2010 at 6:12 PM, Swizec Tellerwrote: > 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.