How do I display dates in a format consistent with the user's computer?

[Neal]

steven:

Neal:

That goes for every standard, and I'm trying to let the reader know.

But this can only lead to confusion unless they ALREADY know.

It's also language-dependent. How about 9 srpen 2004 or listopad 15,
2002?

If the month is in a foreign language, it's natural to assume the text of
the site is in that same foreign language. If I do not understand even the
months in that language, what use is the site to me?

 

[steven]

steven:

But this can only lead to confusion unless they ALREADY know.


If the month is in a foreign language, it's natural to assume the text of
the site is in that same foreign language. If I do not understand even the
months in that language, what use is the site to me?

Yes, that's what David said also.
W3C proposes ISO8601 as standard format, also for XML. Now XML is about much
more than web pages. It's a most ambitious effort to describe *any kind of
information* in a standardised and structured manner. Text documents where
you have to understand the language is just one application. Databases is
another one.
In the information age information exchange is crucial. I already get a lot
more information than I care about (which actually reduces it to plain
data), from anywhere in the world (and outside!), and it's gonna be worse in
the years to come. I don't know how you are gonna cope with it, but I think
we'll need software agents to process all this (filter, merge, link, ...).
I feel that a standard like ISO8601 might be a solution.

Steven

 

[Toby Inkster]

Mind you, even with ISO8601 we'll have a Y10K problem,

I don't see why we should. ISO8601 uses seperators, e.g.

2004-12-22T10:47:03+0000

Simply split it up on /[\-\:\+T/ instead of assuming fixed field lengths.

 

[Greg Schmidt]

In the information age information exchange is crucial. I already get a lot
more information than I care about (which actually reduces it to plain
data), from anywhere in the world (and outside!), and it's gonna be worse in
the years to come. I don't know how you are gonna cope with it, but I think
we'll need software agents to process all this (filter, merge, link, ...).
I feel that a standard like ISO8601 might be a solution.

ISO8601 is certainly how dates should be stored in databases. But the
original question was how to display dates, and I still believe that a
format that uses the name of the month (in whatever language the
document is being generated in) is the way to go.

 

[Greg Schmidt]

Mind you, even with ISO8601 we'll have a Y10K problem,

I don't see why we should. ISO8601 uses seperators, e.g.

2004-12-22T10:47:03+0000

Simply split it up on /[\-\:\+T/ instead of assuming fixed field lengths.

Now, now, with forward thinking like that, we could have avoided the
whole Y2K thing too.

All you programmers reading this through whatever passes for usenet
archives in the 9980s and 9990s, be sure to use fixed width fields. But
be smart and keep notes in a private diary about where you used them.
Then, in 9998 when people belatedly realize what's about to happen, you
can charge exorbitant hourly rates to fix the bugs you put there
intentionally. Also, you can pretend that it took you months to find
all the occurrences, when in fact you spent 90% of the time playing
whatever passes for Halo against your friends who are stuck back on
Earth. If you can manage to "lose" the source code, you can even bill
them for a complete rewrite!

 

[Neal]

In the information age information exchange is crucial. I already get a
lot
more information than I care about (which actually reduces it to plain
data), from anywhere in the world (and outside!), and it's gonna be
worse in
the years to come. I don't know how you are gonna cope with it, but I
think
we'll need software agents to process all this (filter, merge, link,
...).
I feel that a standard like ISO8601 might be a solution.

With data storage and computer communication, I don't disagree - but when
you show it to an average human, make it human-comfortable.

 

[Jukka K. Korpela]

If everybody would have used ISO8601 there would never have been a
Y2K problem.

Not so. ISO 8601 defines a large number of date formats and
specifically allows a two-digit year. This doesn't mean we should use
such options, but the standard _is_ actually rather permissive (as long
as you follow the general principle "more significant first").

But this thread is rather remotely related to HTML. There's nothing in
HTML that would allow any customization of date presentation. And I
don't think this is necessarily a problem, since an HTML document
normally contains text in some human language, so the dates should
follow that language's conventions rather than anything else.

However, using ISO 8601 (with four-digit year of course) might be a
good option at least on multilingual pages. Actually I think that's the
only reasonably choice for _purely numeric_ denotations; 03/04/05 is
just madness, on the World Wide Web at least. So there are really just
two feasible options, illustrated by two examples:
2004-12-11
11. joulukuuta 2004
(Tune the latter to correspond to the rules of the language of the
content.)

 

[Toby Inkster]

ISO8601 is certainly how dates should be stored in databases.

How they are stored in databases is really a matter for the database
implementors -- certainly storage as a floating point number representing
the number of days since the current epoch is the most common way -- it's
more disk-space efficient than ISO8601 and allows for faster processing.

Of course, communicating the date to other programs that query the
database is a different matter -- and ISO8601 is certainly a good idea in
such a case.

Aside: Useful cheat to get the current ISO8601 date in either Perl or PHP
on Linux:

$isodate = `/bin/date -Is`;

(The string will be padded on the end with a new line character.)