Re: International standard for date and time
On Sun, 2007-06-17 at 01:58 +, [EMAIL PROTECTED] wrote: > > > On Jun 16, 6:45 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > > On 6/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > > However all that is beside the point. The patch that Jonas has posted in > > > #4590 is just to change the default settings. I'm not sure if that's > > > worth doing or not. Currently I'm somewhere between -0 and +0, since > > > it's completely within the control of the application user, so it's > > > basically a non-event (also the patch should have been against > > > global_settings.py, not settings.py, but that's a minor thing). > > > > Yeah, I started writing my reply before I saw the follow-up patch. > > > > Looking at what's come up since then, I feel like this is a bikeshed > > problem and probably not worth spending time on; the fact that default > > formats are within the control of the person deploying Django (through > > documented settings), and easily overridden on a case-by-case basis > > (through explicit date format strings when needed, as in template > > output), says to me that this isn't a big deal and that the default is > > pretty much arbitrary. > > > > So I'd be -0 at best here; replacing one arbitrary default with > > another arbitrary default doesn't strike me as a particularly pressing > > change ;) > > > > -- > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > correct." > > The dateformat year, month, day or year, day, month should be part of > each language translation and have a default. You realise we already have settings.DATE_FORMAT and settings.DATETIME_FORMAT, both of which are translated strings, right? Apps that wish to display localised strings should use those settings. It isn't perfect, since if somebody changes DATE_FORMAT in their settings.py, that is the string used to seek out the translation, so it might not be translated. However it might not be possible to have a perfect solution there. There is always a conflict between the app installer having some control over date/time formats and the translations of that information. If the default isn't correct, the default translation also might not be correct. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
Since this has come up, may I point you to this discussion over here: http://groups.google.com/group/Django-I18N/browse_thread/thread/3f5dfb2a9a10f904/54365cef61f62f21?lnk=st==1#54365cef61f62f21 About ticket 4147: http://code.djangoproject.com/ticket/4147 On Jun 17, 4:58 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On Jun 16, 6:45 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > > > > > On 6/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > However all that is beside the point. The patch that Jonas has posted in > > > #4590 is just to change the default settings. I'm not sure if that's > > > worth doing or not. Currently I'm somewhere between -0 and +0, since > > > it's completely within the control of the application user, so it's > > > basically a non-event (also the patch should have been against > > > global_settings.py, not settings.py, but that's a minor thing). > > > Yeah, I started writing my reply before I saw the follow-up patch. > > > Looking at what's come up since then, I feel like this is a bikeshed > > problem and probably not worth spending time on; the fact that default > > formats are within the control of the person deploying Django (through > > documented settings), and easily overridden on a case-by-case basis > > (through explicit date format strings when needed, as in template > > output), says to me that this isn't a big deal and that the default is > > pretty much arbitrary. > > > So I'd be -0 at best here; replacing one arbitrary default with > > another arbitrary default doesn't strike me as a particularly pressing > > change ;) > > > -- > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > correct." > > The dateformat year, month, day or year, day, month should be part of > each language translation and have a default. > > The problem with explicit is if you have a multilanguage project you > can't make it pick the correct one easily. > > +0.5 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
On 6/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > However all that is beside the point. The patch that Jonas has posted in > #4590 is just to change the default settings. I'm not sure if that's > worth doing or not. Currently I'm somewhere between -0 and +0, since > it's completely within the control of the application user, so it's > basically a non-event (also the patch should have been against > global_settings.py, not settings.py, but that's a minor thing). Yeah, I started writing my reply before I saw the follow-up patch. Looking at what's come up since then, I feel like this is a bikeshed problem and probably not worth spending time on; the fact that default formats are within the control of the person deploying Django (through documented settings), and easily overridden on a case-by-case basis (through explicit date format strings when needed, as in template output), says to me that this isn't a big deal and that the default is pretty much arbitrary. So I'd be -0 at best here; replacing one arbitrary default with another arbitrary default doesn't strike me as a particularly pressing change ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
On Sun, 2007-06-17 at 02:50 +0200, Julian 'Julik' Tarkhanov wrote: > > On Jun 17, 2007, at 2:46 AM, Jonas wrote: > > > > > > > On 17 jun, 01:14, "James Bennett" <[EMAIL PROTECTED]> wrote: > > > Where do you propose this be used? At the database level, your DB > > > will > > > store date/time values in whatever internal format it prefers. > > Yes, I think that should be stored so at the database level. > > > Databases store dates internally, not strings. Aside from databases > being unable to handle dates-times before the epoch this is > not a big problem. The only place where ISO formats are appropriate > are in machine-readable output (i.e. RSS/ATOM, web services and the > like). There's a danger that everybody is starting to talk at cross-purposes here (including the original poster). Database storage format is irrelevant, since, as Julian points out, it's an internal format and unrelated to the presentation style. On the other hand, ISO formats have a lot more applications than merely machine-readable output, so it's not valid to dismiss them on those grounds. However all that is beside the point. The patch that Jonas has posted in #4590 is just to change the default settings. I'm not sure if that's worth doing or not. Currently I'm somewhere between -0 and +0, since it's completely within the control of the application user, so it's basically a non-event (also the patch should have been against global_settings.py, not settings.py, but that's a minor thing). So there's no massive (or even minor) change of functionality being proposed here; it's just a proposed change in the defaults. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
On Jun 17, 2007, at 2:46 AM, Jonas wrote: > > On 17 jun, 01:14, "James Bennett" <[EMAIL PROTECTED]> wrote: >> Where do you propose this be used? At the database level, your DB >> will >> store date/time values in whatever internal format it prefers. > Yes, I think that should be stored so at the database level. Databases store dates internally, not strings. Aside from databases being unable to handle dates-times before the epoch this is not a big problem. The only place where ISO formats are appropriate are in machine-readable output (i.e. RSS/ATOM, web services and the like). -- Julian 'Julik' Tarkhanov please send all personal mail to [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
On 17 jun, 01:14, "James Bennett" <[EMAIL PROTECTED]> wrote: > Where do you propose this be used? At the database level, your DB will > store date/time values in whatever internal format it prefers. Yes, I think that should be stored so at the database level. > At the > level of input and output to clients over the Web, it's vastly > preferable to accept and return date/time values in a format expects > by users (e.g., if your users are American, you might want to return > "7:30 PM 6/16/07", but if they're French "19h30 16/6/07" might be > preferable). And internally, dates and times are represented by > Python's 'date' and 'datetime' classes. But what happens if your hearing is international or isn't the localization for a country? Aside from this that format it has many advantages as they are indicated here: http://www.cl.cam.ac.uk/~mgk25/iso-time.html --- * easily readable and writeable by software (no 'JAN', 'FEB', ... table necessary) * easily comparable and sortable with a trivial string comparison * language independent * can not be confused with other popular date notations * consistency with the common 24h time notation system, where the larger units (hours) are also written in front of the smaller ones (minutes and seconds) * strings containing a date followed by a time are also easily comparable and sortable (e.g. write "1995-02-04 22:45:00") * the notation is short and has constant length, which makes both keyboard data entry and table layout easier * identical to the Chinese date notation, so the largest cultural group (>25%) on this planet is already familiar with it :-) * date notations with the order "year, month, day" are in addition already widely used e.g. in Japan, Korea, Hungary, Sweden, Finland, Denmark, and a few other countries and people in the U.S. are already used to at least the "month, day" order * a 4-digit year representation avoids overflow problems after 2099-12-31 --- > So where are you proposing to switch things? The ideal would be that those data were stored following that standard (database level). And optionally were showed (over the web) at the user according to its localization. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
On 6/16/07, Jonas <[EMAIL PROTECTED]> wrote: > I think that Django should use an international standard date and time > format. Where do you propose this be used? At the database level, your DB will store date/time values in whatever internal format it prefers. At the level of input and output to clients over the Web, it's vastly preferable to accept and return date/time values in a format expects by users (e.g., if your users are American, you might want to return "7:30 PM 6/16/07", but if they're French "19h30 16/6/07" might be preferable). And internally, dates and times are represented by Python's 'date' and 'datetime' classes. So where are you proposing to switch things? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
For if you want follow that standard I've added a patch: http://code.djangoproject.com/ticket/4590 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
International standard for date and time
I think that Django should use an international standard date and time format. For more information: http://www.cl.cam.ac.uk/~mgk25/iso-time.html http://www.w3.org/QA/Tips/iso-date http://en.wikipedia.org/wiki/ISO_8601 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update III: Django REST interface
This is the third weekly status update for my Summer of Code project, a generic REST interface for Django [1]. I spent the SoC-part of this week mostly thinking about automated URL pattern generation, wrote some code and added a few tests that demonstrate how to use this feature. Currently, you can: 1. Let the REST interface generate all your API URLs automatically. 2. Give a custom base URL and let the REST interface do the rest. 3. Subclass model_resource.Collection, overwrite Collection.get_entry and (if you want to filter the data returned) Collection.read, and use arbitrary custom URLs. I am not completely happy with how this works yet. Using custom URLs should be as intuitive as using automated URLs, and I don't think that's the case yet. If you see how things could be improved, please let me know. Other changes I made this week include the option to restrict model field access via expose_fields and better error handling (all exceptions are caught in Collection.dispatch, the Responder class is responsible for returning a nicely formatted error message). Besides thinking about how custom RESTful URLs could be implemented in a more intuitive way, my main task for next week is to think about the relationship between the REST interface and authentication. It should be possible to have different levels of access for authenticated and unauthenticated users. Criticism, ideas and suggestions are welcome! Regards, Andreas [1] http://code.google.com/p/django-rest-interface/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: multidb and trunk
On Sat, 2007-06-16 at 20:15 +, dimas wrote: > Hello all, > > Is it hard to port multidb features against trunk? > > Or any info on how ready is it to get merged? Perhaps you might want to read this: http://groups.google.com/group/django-developers/browse_frm/thread/18d57576c054701e/c391e06e82696712?lnk=gst=multidb=2#c391e06e82696712 Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
multidb and trunk
Hello all, Is it hard to port multidb features against trunk? Or any info on how ready is it to get merged? Thanks in advance. WBR, dimas --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
[newforms-admin] I want to add an admin option:section_name
I've created the ticket(http://code.djangoproject.com/ticket/4589) and uploaded a patch, i post it here for you discuss, it's quite simple and i hope it to be accepted ： > Currently, admin interface use app label to group models into sections and > use app label as the section name, but i think use a admin option to specify > the section name would be more flexibly (e.g. you can use non-ascii > character in the option but can't do that in app label, and the models in > the same app can be displayed in several sections). > > I named this option as section_name currently. > > If not specified, the value of section_name is the same as app_label. > > I've been using this feature widely, and i hope it can be accepted. > -- http://codeplayer.blogspot.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
