International standard for date and time
Jonas
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
Jonas
James Bennett
> 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."
Jonas
> 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.
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.
Julian 'Julik' Tarkhanov
On 17 jun, 01:14, "James Bennett" <ubernost...@gmail.com> wrote:Where do you propose this be used? At the database level, your DB willstore date/time values in whatever internal format it prefers.Yes, I think that should be stored so at the database level.
Malcolm Tredinnick
>
> On Jun 17, 2007, at 2:46 AM, Jonas wrote:
>
> >
> >
> > On 17 jun, 01:14, "James Bennett" <ubernost...@gmail.com> 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
James Bennett
> 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 ;)
oyvind....@gmail.com
On Jun 16, 6:45 pm, "James Bennett" <ubernost...@gmail.com> wrote:
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
orestis
About ticket 4147: http://code.djangoproject.com/ticket/4147
On Jun 17, 4:58 am, "oyvind.salt...@gmail.com"
Malcolm Tredinnick
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
Tai Lee
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.
Malcolm Tredinnick
The current settings already are unambiguous.
Malcolm
Jonas
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.
Jonas
> (also the patch should have been against
> global_settings.py, not settings.py, but that's a minor thing).
Mike H
I needed a nice way of saying "mike's friends" in a template when the
currently logged in user was "mike", but "james' friends" when it was
james. I realise this is a very English biased filter, but here's a
patch to add it to defaultfilters in template.
Cheers,
MikeH
--- django0.96/template/defaultfilters.py 2007-03-10
08:11:28.000000000 +0000
+++ django/template/defaultfilters.py 2007-06-17 20:02:50.000000000 +0100
@@ -551,6 +551,15 @@
pass
return singular_suffix
+def possesive(value):
+ """
+ Returns a possesive form of a name according to English rules
+ Mike returns Mike's, while James returns James'
+ """
+ if value[-1] == 's':
+ return "%s'" % value
+ return "%s's" % value
+
def phone2numeric(value):
"Takes a phone number and converts it in to its numerical equivalent"
from django.utils.text import phone2numeric
@@ -593,6 +602,7 @@
register.filter(make_list)
register.filter(phone2numeric)
register.filter(pluralize)
+register.filter(possesive)
register.filter(pprint)
register.filter(removetags)
register.filter(random)
Mike H
patch!
Cheers,
MikeH
--- django0.96/template/defaultfilters.py 2007-03-10
08:11:28.000000000 +0000
+++ django/template/defaultfilters.py 2007-06-17 20:02:50.000000000 +0100
@@ -551,6 +551,15 @@
pass
return singular_suffix
+def possessive(value):
+ """
+ Returns a possessive form of a name according to English rules
+ Mike returns Mike's, while James returns James'
+ """
+ if value[-1] == 's':
+ return "%s'" % value
+ return "%s's" % value
+
def phone2numeric(value):
"Takes a phone number and converts it in to its numerical equivalent"
from django.utils.text import phone2numeric
@@ -593,6 +602,7 @@
register.filter(make_list)
register.filter(phone2numeric)
register.filter(pluralize)
+register.filter(possessive)
register.filter(pprint)
register.filter(removetags)
register.filter(random)
Malcolm Tredinnick
> On 17 jun, 09:03, Malcolm Tredinnick <malc...@pointy-stick.com> 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
Malcolm Tredinnick
> Hi all,
>
> I needed a nice way of saying "mike's friends" in a template when the
> currently logged in user was "mike", but "james' friends" when it was
> james. I realise this is a very English biased filter, but here's a
> patch to add it to defaultfilters in template.
Please (a) start a new thread for a new topic rather than just replying
to an unrelated post and (b) post patches to Trac so that they don't get
lost and can be reviewed in due course.
Thanks,
Malcolm
Mike H
groups would file the email as it did, I thought I was starting a new
discussion.
I'll keep it in mind in future :)
Mike
Jonas
> 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.
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?
Malcolm Tredinnick
around in circles now.
On Mon, 2007-06-18 at 12:09 -0700, Jonas wrote:
> On 18 jun, 00:04, Malcolm Tredinnick <malc...@pointy-stick.com> 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 state of affairs.
There are always alternative choices for things like this. We have to
choose one. You would prefer we made a different choice, but there are
as many arguments against that as against the current system; they are
just different arguments. As I've mentioned a couple of time, Django's
choice errs on the side of being like the strings you would see in a
newspaper or on a sign on the street. We've also made it customisable
for those who want something different on their site and translatable so
that other locales can use their more traditional formats. I think that
comes close to covering all bases.
Best wishes,
Malcolm
Jonas
> I'm going to give this one more pass and then dropout. We're just going
> around in circles now.
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!
Tom Tobin
>
> On 18 jun, 23:17, Malcolm Tredinnick <malc...@pointy-stick.com> 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. "YYYY-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 ::
James Bennett
> 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)
Nicola Larosa
>> 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