KIPS (Keep It Personal, Stupid!) [was: Re: International standard for date and time]
> Jonas wrote: >> I remember to you that we are to interacting with computers, not with >> persons. James Bennett wrote: > The problem is that we're not really "interacting with computers". > We're using computers as proxies to help us interact with *people*, > and they should be first in our thoughts at all times. Very well said, and easily and sadly forgotten, sometimes. In this day and age, these machines are not mere computing devices, nor "ordinateurs": they are communicators, conveying and embodying many facets of the human beings that use them. (Many other human facets still elude our machines, but that would be doubly off-topic. ;-) ) -- Nicola Larosa - http://www.tekNico.net/ I'm not expecting Ubuntu to be perfect, but I am now certain it will be enough better to compensate me for the fact that I need to learn a new set of administration tools. Fedora, you had every advantage, and you had my loyalty, and you blew it. And that is a damn, dirty shame. -- Eric S. Raymond, February 2007 --~--~-~--~~~---~--~~ 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/19/07, Jonas <[EMAIL PROTECTED]> wrote: > It's true that we are around circles, and I understand that you wann't > make that little change. It's more comfortable to have the framework > configured to your localization that: And it's already quite easy to do so, just by changing a couple settings. Why are we still going around about the default value? > * to thinking in in the rest of people > * doesn't continue believing that USA is the world > * and that the international standards, -created to facilitate the > data interchange between all countries-, are not worthy for them. Whoa, there, cowboy! You do know that among the core Django developers we have representatives of multiple countries, right? Plus, I have it on good authority that one of the American committers is actually part of a secret Ukrainian conspiracy to hook the US on gypsy jazz, though I'm not sure how they plan to profit from it. And Malcolm, who's lobbying against this change, is an Aussie who knows how to fly a hovercraft full of eels in more languages than I can count, so I'm not really seeing any US imperialism artfully hidden in the default value of the DATE_FORMAT setting. > Only 3 countries in all world have not adopted it. I'm sure that you > guess one of them. I guess it :P My car gets forty rods to the hogshead, and that's the way I like it! > I remember to you that we are to interacting with computers, not with > persons. It's by that reason that the operating systems show date and > time in that format -at least in my Debian- but it's possible that > you're using Windows. The problem is that we're not really "interacting with computers". We're using computers as proxies to help us interact with *people*, and they should be first in our thoughts at all times. I'm going to stand by my earlier -1: this is a bikeshed issue, and we've already painted it an arbitrary color and shipped instructions on how to change it if people want to ;) (though if we really want to be culturally agnostic, I'll nominate the Mesoamerican "long count", which nobody really uses anymore, so everyone would want to change the default setting to their own culture's preference. Plus, once we get over the dreaded y2k12 problem from rolling over a thirteenth b'ak'tun, it'll be stable again until around 6100 AD) -- "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 6/19/07, Jonas <[EMAIL PROTECTED]> wrote: > > On 18 jun, 23:17, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > I'm going to give this one more pass and then dropout. We're just going > > around in circles now. > It's true that we are around circles, and I understand that you wann't > make that little change. It's more comfortable to have the framework > configured to your localization that: > > * to thinking in in the rest of people > * doesn't continue believing that USA is the world > * and that the international standards, -created to facilitate the > data interchange between all countries-, are not worthy for them. > > Indeed I just read the next news that leaves very clear what I am > saying: > http://digg.com/general_sciences/Nations_who_have_not_yet_adopted_the_metric_system_pic > > "Nations who have not yet adopted the metric system" > Only 3 countries in all world have not adopted it. I'm sure that you > guess one of them. I guess it :P Besides the fact that you're being utterly unproductive with your combative attitude here, you *do* realize Malcolm is Australian, right? Furthermore, you're trying to "shame" a project that has a stellar internationalization track record. Trust me -- these guys "get it". Apparently, you don't. > > Do you really say 2007-06-18 when your friends ask you what the date is? > > Does your grandmother, who doesn't use computers as much as you do, use > > that format? We are trying to encourage websites that feel natural to > > all users, not just friendly for people who have used computers all > > their lives. > I remember to you that we are to interacting with computers, not with > persons. It's by that reason that the operating systems show date and > time in that format -at least in my Debian- but it's possible that > you're using Windows. Did you miss the point, stated several times, that all of this has *nothing* to do with the internal representation of the date/time? Changing the format will have *nothing* to do with how your server stores the time. "-MM-DD HH:MM:SS" is just as much a *human* convention as any other textual date/time format; the database *does not* store the date like that. :: sighs and goes back to doing more productive things :: --~--~-~--~~~---~--~~ 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 18 jun, 23:17, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I'm going to give this one more pass and then dropout. We're just going > around in circles now. It's true that we are around circles, and I understand that you wann't make that little change. It's more comfortable to have the framework configured to your localization that: * to thinking in in the rest of people * doesn't continue believing that USA is the world * and that the international standards, -created to facilitate the data interchange between all countries-, are not worthy for them. Indeed I just read the next news that leaves very clear what I am saying: http://digg.com/general_sciences/Nations_who_have_not_yet_adopted_the_metric_system_pic "Nations who have not yet adopted the metric system" Only 3 countries in all world have not adopted it. I'm sure that you guess one of them. I guess it :P > Do you really say 2007-06-18 when your friends ask you what the date is? > Does your grandmother, who doesn't use computers as much as you do, use > that format? We are trying to encourage websites that feel natural to > all users, not just friendly for people who have used computers all > their lives. I remember to you that we are to interacting with computers, not with persons. It's by that reason that the operating systems show date and time in that format -at least in my Debian- but it's possible that you're using Windows. -- For Linux only: Run *ls -lF* into a shell directory and you can see the date and time on international format. -- --- I'm consequent with I'm saying but I wann't to offend nobody. I hope that nobody feels like victim Greetings! --~--~-~--~~~---~--~~ 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
I'm going to give this one more pass and then dropout. We're just going around in circles now. On Mon, 2007-06-18 at 12:09 -0700, Jonas wrote: > On 18 jun, 00:04, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-06-17 at 06:13 -0700, Jonas wrote: [...] > The problem is that you think that everybody would have to know the > english months names, By default, Django uses (North American) English. So, yes, we do assume people know English when using Django in the default locale. If they don't, that is what the very comprehensive translation infrastructure is for. Month names are not going to be the greatest hurdle for a non-English speaker here. > and to feel comfortable with the USA date > format. > In USA is used: *Month Day Year*. But in another countries the people > could use another formats like *Day Month Year* In many countries multiple variations on the theme are used in different contexts and there isn't mass confusion. Let's try to get past the notion that there is a single format used uniformly throughout any individual country. > > They are all also marked as translatable by Django, so people using > > other languages see localised, similarly unambiguous versions of those > > strings. > I'm agree. But the settings should be set by default to that > international format by I just say in the anterior paragraph. You assert this, but without supporting arguments except pointing to some documents that use benefits and drawbacks we already acommodate. The (extra, not mentioned in the links you gave) reason we can use the current format is that it's a very familiar format for native English speakers. There isn't any ambiguity and it looks like it was written to be read by humans and not computers. Humans think of months as January, February, March, etc, not 1, 2, 3, 4... > > > > Django is a project used by an international community (and grown by > > > that community) and its configuration should be set to an > > > international format by default. > > > > "International format" can mean a lot of things, not all of them good. > > One very strong argument against using an ISO format (which is > > well-defined and is what the original ticket was about) is that it isn't > > a very human-friendly string. If your friends asks you what the date is, > > you don't say "2007-06-18", you say "June 18". The goal of a date format > > is to unambiguously describe the date and time in a way that is > > understood by the reader. That is the main justification given in the > > links you posted earlier, too, if you have a look. However, none of > > those links address the human-readable phase particularly clearly. We > > meet the unambiguous and clear in all locale requirements with our > > current setup. If a website says "today is 2007-06-18 08:52", it is > > designed for people who are very familiar with computers and willing to > > compensate for some odd constructs like that; it isn't written to be > > invisible. > It has not been created to be human-friendly else so that it can be > understood by anyone. This assertion (not user friendly) is not something I can agree with. Month names are particularly friendly to humans. It's why we invented them. Which group of English speakers does not understand June 18, 2007? They may choose to use "18 June 2007" sometimes, but they will understand the reverse format without even thinking, where as "2007-06-18 09:32" requires some parsing (is it this month? next month?...). Do you really say 2007-06-18 when your friends ask you what the date is? Does your grandmother, who doesn't use computers as much as you do, use that format? We are trying to encourage websites that feel natural to all users, not just friendly for people who have used computers all their lives. > That's the function of an international format. It's also a function supported by other formats. This isn't an either/or discriminator. > I don't say that location of date and time shouldn't be used, else > that by defect would have to be selected the international format. Or > perhaps, does Django has the location about date and time for all > countries? I don't understand what you're trying to say here. However, if I'm guessing right, I think your concerns can be addressed by pointing out that if your particular locale has a very uniform date time format and it matches the ISO format, that is something the translator for your locale should be using. The default date and time format strings are all translated strings. So the translator for a locale that always uses ISO format should be putting that format into the PO file for DATE_FORMAT, etc. Realistically, there isn't going be an answer that everybody agrees with 100% for this issue. The fact that you feel it is such a serious thing shows that. However, your proposal also hasn't collected any significant support that has raised issues that aren't already addressed, so I can't see it as a really serious problem with the current
Re: International standard for date and time
On 18 jun, 00:04, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2007-06-17 at 06:13 -0700, Jonas wrote: > > The current settings already are unambiguous *only for north > > americans*. > > I'm sorry, but this simply isn't true. > > - Current default DATE_FORMAT is "N j, Y" which, right this > minute, produces "Jun. 18, 2007". > > - Current default DATETIME_FORMAT is 'N j, Y, P' which produces > "Jun. 18, 2007, 8:52 a.m.". > > - Current default TIME_FORMAT is "P" which produces 8:52 a.m. > > - YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT similarly use words for > the month and four digit years. > > None of those are ambiguous. You might quibble (as I would) that using > month abbreviations rather than thefull name there is a flaw, but it's > not fatal and there is absolutely zero doubt about what month, date, > year, hour, minute and half of the day is being referenced. No matter > what your particular locale, providing you know the English month > names. The problem is that you think that everybody would have to know the english months names, and to feel comfortable with the USA date format. In USA is used: *Month Day Year*. But in another countries the people could use another formats like *Day Month Year* > They are all also marked as translatable by Django, so people using > other languages see localised, similarly unambiguous versions of those > strings. I'm agree. But the settings should be set by default to that international format by I just say in the anterior paragraph. > > Django is a project used by an international community (and grown by > > that community) and its configuration should be set to an > > international format by default. > > "International format" can mean a lot of things, not all of them good. > One very strong argument against using an ISO format (which is > well-defined and is what the original ticket was about) is that it isn't > a very human-friendly string. If your friends asks you what the date is, > you don't say "2007-06-18", you say "June 18". The goal of a date format > is to unambiguously describe the date and time in a way that is > understood by the reader. That is the main justification given in the > links you posted earlier, too, if you have a look. However, none of > those links address the human-readable phase particularly clearly. We > meet the unambiguous and clear in all locale requirements with our > current setup. If a website says "today is 2007-06-18 08:52", it is > designed for people who are very familiar with computers and willing to > compensate for some odd constructs like that; it isn't written to be > invisible. It has not been created to be human-friendly else so that it can be understood by anyone. That's the function of an international format. I don't say that location of date and time shouldn't be used, else that by defect would have to be selected the international format. Or perhaps, does Django has the location about date and time for all countries? --~--~-~--~~~---~--~~ 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 06:13 -0700, Jonas wrote: > On 17 jun, 09:03, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-06-17 at 00:54 -0700, Tai Lee wrote: > > > +1 - it's a simple default settings change. django is used by an > > > international community, so the defaults should be a format that is > > > understood by everybody without any possibility of ambiguity. those > > > that prefer a different format (american, or abbreviated or full > > > length month names etc) can change their settings. > > > > The current settings already are unambiguous. > > The current settings already are unambiguous *only for north > americans*. I'm sorry, but this simply isn't true. - Current default DATE_FORMAT is "N j, Y" which, right this minute, produces "Jun. 18, 2007". - Current default DATETIME_FORMAT is 'N j, Y, P' which produces "Jun. 18, 2007, 8:52 a.m.". - Current default TIME_FORMAT is "P" which produces 8:52 a.m. - YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT similarly use words for the month and four digit years. None of those are ambiguous. You might quibble (as I would) that using month abbreviations rather than thefull name there is a flaw, but it's not fatal and there is absolutely zero doubt about what month, date, year, hour, minute and half of the day is being referenced. No matter what your particular locale, providing you know the English month names. They are all also marked as translatable by Django, so people using other languages see localised, similarly unambiguous versions of those strings. > Django is a project used by an international community (and grown by > that community) and its configuration should be set to an > international format by default. "International format" can mean a lot of things, not all of them good. One very strong argument against using an ISO format (which is well-defined and is what the original ticket was about) is that it isn't a very human-friendly string. If your friends asks you what the date is, you don't say "2007-06-18", you say "June 18". The goal of a date format is to unambiguously describe the date and time in a way that is understood by the reader. That is the main justification given in the links you posted earlier, too, if you have a look. However, none of those links address the human-readable phase particularly clearly. We meet the unambiguous and clear in all locale requirements with our current setup. If a website says "today is 2007-06-18 08:52", it is designed for people who are very familiar with computers and willing to compensate for some odd constructs like that; it isn't written to be invisible. Barring any particularly strong arguments in favour of this change, I'm becoming more and more inclined to "wontfix" this, since changing it adds work for translators and it's already something that is entirely under the control of project installers in any case. 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 17 jun, 02:01, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > (also the patch should have been against > global_settings.py, not settings.py, but that's a minor thing). It's already corrected. --~--~-~--~~~---~--~~ 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, 09:03, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2007-06-17 at 00:54 -0700, Tai Lee wrote: > > +1 - it's a simple default settings change. django is used by an > > international community, so the defaults should be a format that is > > understood by everybody without any possibility of ambiguity. those > > that prefer a different format (american, or abbreviated or full > > length month names etc) can change their settings. > > The current settings already are unambiguous. The current settings already are unambiguous *only for north americans*. Django is a project used by an international community (and grown by that community) and its configuration should be set to an international format by default. --~--~-~--~~~---~--~~ 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 00:54 -0700, Tai Lee wrote: > +1 - it's a simple default settings change. django is used by an > international community, so the defaults should be a format that is > understood by everybody without any possibility of ambiguity. those > that prefer a different format (american, or abbreviated or full > length month names etc) can change their settings. The current settings already are unambiguous. 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
+1 - it's a simple default settings change. django is used by an international community, so the defaults should be a format that is understood by everybody without any possibility of ambiguity. those that prefer a different format (american, or abbreviated or full length month names etc) can change their settings. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---