FAQ Topic - How do I format a date with javascript? (2009-06-01)

[Michael J. Ryan]

The reasons why YYYY-MM-DD is best for machine use are equally valid for
human use; it's better than DD/MM/YYYY or the absurd MM/DD/YYYY.

I, personally find it the most readily recognizable format, when dealing
internationally, even if a bit alien by most, it's the best available short
date format. For example 10/01/2009 is that the past, or future? with users
in differing locals, there's no certainty. YYYY-MM-DD there's no obscurity.

 

[Evertjan.]

Dr J R Stockton wrote on 14 jun 2009 in comp.lang.javascript:

In comp.lang.javascript message <[email protected]>

Dr J R Stockton wrote on 13 jun 2009 in comp.lang.javascript:

One cannot expect Americans to consider international standards, [...]

But they're not all bad - remember J Jerome.

according to other standards remember it would be Jerome J.

Are you sure that you are thinking of the correct J Jerome?

Yes, the Jerome I am thinking of, is the one I am thinking of.

Not neccessarily matching the one you were implying
as a correct standard J.J.

There could even be a third Jerome, all three taking a boat trip.

<http://upload.wikimedia.org/wikipedia/commons/5/5d/Jerome_K._Jerome.jpg>

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Sat, 13 Jun 2009 17:35:46, Garrett Smith


Any known sort of non-date result is easy enough to check - if the
developer thinks of it.

Compared to "Invalid Date", "" does not require l10n, is easier to
spell, and can be used in boolean context with a predictable outcome.

var result = formatDate(myDate);
if(!result) {
// handle this situation.
}

The intent should be for it to be a good routine, not liable to give
undetected error in actual use. The most probable reason for creating a
date string is to write it to a medium outside the program - the screen,
a file, a comms link, for example.

To encourage testing the result, one can make the function return a
(non-Date) object. For input, I have one in which such an object has
two properties. The first is 3 for a pattern error, 1 for a YMD error,
and false for a good date, in which case the second property is a Date
Object. One is then encouraged to write something like
if (result.Bad) <handleError>
<use> result.D

Function formatDate does not return an object. Any object, such as your
hypothetical "non-date object", would be wrong. At the very least, the
returned value should be consistent. Function formatDate returns a
string value.

The callee, in this case, just returns its value. That value can be
passed to another method M which builds an object, builds and returns
another string, or has behavioral side effects, such as updating the UI
or sending the value to the server.

That would certainly help.

I do not know which are "common" or how common they are, or what the
statistical understandability of each is.

Researcher: [shows card "2002-11-12"]
Subject (American): "November 12, two thousand and two".

Researcher: [shows card "1952-02-12T10:27:29"]
Subject (British): Arse!

That is not a date; not today's, not even that of HM's first Tuesday as
such. It has a separator not expected to be presented to people; and it
has a time; and we would not use that word ("Ass" implies "fool", and
the vulgar prefer more potent words. Granted, that's why Malvern hosted
an RSRE).

How do you know the separator is not expected to be presented to people?
The "T" should not be too confusing.

You should be an editor. You are not called on to write about what you
do not know.

What is the official reference I may cite for "most common formats"?

Even RFC 3339, sec 5.2 does not nail down recommended formats.

"Common formats" depends on frequency of use. "Understandable" depends
on who is doing the reading, and to make a blanket statement about what
can be expected to be understood requires some research. That is
something I have not seen.

What is lacking are reliable resources for 1) "common" formats and 2)
"understandable".

Your suggested text mentions sortability. That is mentioned twice in the
Kuhn document. It could be included with a paragraph on the FAQ. As you
mentioned, or could be linked.

A revision to the Dates main entry, with:
1) "common formats" removed.
2) your previous suggested text added to the top:
3) Link to Kunh document and changes to order of links.

| Unlike others, ISO 8601 formats are language-independent and
| unambiguous world-wide; and, for years 0000-9999, are of constant
| lengths and are sortable as strings. easily readable and writable by
| software
| The most common ISO 8601 Extended format, YYYY-MM-DD, can be
| understood world-wide, without ambiguity.
|
| Never use a local date/time format for a non-local event. Instead, use
| UTC, as in ISO 8601 YYYY-MM-DDThh:mm:ssZ ( Z is the only letter
| suffix).
|
| For a local date/time with time offset, to unambiguously indicate a
| particular instant, use ISO 8601 format YYYY-MM-DDThh:mm:ss±hh:mm.
|
| The T may be omitted where doing so would not cause ambiguity. For an
| SQL date, it must be replaced by a single space.
|
| Never use a local date/time format for a non-local event. Instead, use
| UTC, as in ISO 8601 YYYY-MM-DDThh:mm:ssZ ( Z is the only letter
| suffix).
|
| For a local date/time with time offset, to unambiguously indicate a
| particular instant, use ISO 8601 format YYYY-MM-DDThh:mm:ss±hh:mm.
|
| The T may be omitted where doing so would not cause ambiguity. For an
| SQL date, it must be replaced by a single space.
|
| See also:
| * ISO 8601:2004(E)
| * ECMA-262 Date.prototype, s. 15.9
| * International Standard Date and Time Notation, by Markus Kuhn
| * http://en.wikipedia.org/wiki/ISO_8601
| * W3C QA Tip: Use international date format (ISO)

Well, (\D|$)

Ug. I don't know why I let that slip by me. Yes, that need immediate
attention. I think \s is simple and works in most cases.

I searched 67 days of this newsgroup, omitting spam. There are 121
"if(" and 387 "if (". The FAQ contains 8 of the former (several written
by you) and two of the latter, so the difference in non-FAQ use will be
greater.

It sounds like you are suggesting that the more common convention is to
have a space before the opening parenthesis in an |if| statement because
using a space following the "if" in an |if statement| is according to
your search results (I can't verify), much more popular.

That may be true, but I see no good reason for it. I don't see how it
avoids ambiguity with a function call, as no function could be named
|if| and functions can have a space following the identifier.

[...]

Code for the FAQ **must** be copy'n'pasted from working tested code.
Hand-copying or adjusting is unreliable.

It cannot be done that way. The character > must be converted to an
entity for HTML. That entity is "&gt;". To generate that entity, the xml
contains &amp;gt;.

Garrett

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Mon, 15 Jun 2009 15:17:47, Garrett Smith

Function formatDate does not return an object.

It does not; but it could. It could return {Bad:errortype, DS:string}.

Then one could use
formatDate(D).DS
if (formatDate(D).Bad) return
if (!(Z=formatDate(D)).Bad) S = Z.DS
etc.
depending on the circumstances of use.
If the Bad field amounts to true, the DS field could be missing, an
empty string, or a cautionary remark.

How do you know the separator is not expected to be presented to
people? The "T" should not be too confusing.

Ask someone to pen the date and time; then ask why they put a space
character rather than one needing ink; then listen to the consequent
aspersions on your intellect.

What is the official reference I may cite for "most common formats"?

You are getting rather like Thomas.




= ISO 8601 date/time formats are language-independent and
= unambiguous world-wide; and, for years 0000-9999, of constant
= lengths and sortable as strings. Its Extended format for common date
= is YYYY-MM-DD, and for time is hh:mm:ss.

= Never use a local date/time format for a non-local event. Instead, use
= UTC, as in YYYY-MM-DDThh:mm:ssZ (Z is the only letter suffix).

= For a local date/time offset from UTC, use YYYY-MM-DDThh:mm:ss±hh:mm.

= The T can be replaced by whitespace; for SQL, it must be replaced by a
= single space.


You are still not reading what you post. There is no need to repeat
paragraphs.

| See also:
| * ISO 8601:2004(E)
| * ECMA-262 Date.prototype, s. 15.9
| * International Standard Date and Time Notation, by Markus Kuhn
| * http://en.wikipedia.org/wiki/ISO_8601
| * W3C QA Tip: Use international date format (ISO)



Ug. I don't know why I let that slip by me. Yes, that need immediate
attention. I think \s is simple and works in most cases.

\s will not work if no space is present. Unless checking exact format,
a date followed by punctuation should be acceptable, and also
"2009-06-16Fri". But a third day-of-month digit should give a pattern
error. See current <js-faq.htm>.

It sounds like you are suggesting that the more common convention is to
have a space before the opening parenthesis in an |if| statement
because using a space following the "if" in an |if statement| is
according to your search results (I can't verify), much more popular.

After reading the middle of that paragraph, I know that at least one of
us is confused.

That may be true, but I see no good reason for it. I don't see how it
avoids ambiguity with a function call, as no function could be named
|if| and functions can have a space following the identifier.

I did not say that it was ambiguous; I said that it looks like a
function call. Some would say that "If(OK)" shows a function call - in
strict JavaScript terms, it must be; but in practice it's most probably
a typo and otherwise a remarkable choice of function name.

When written, code should be spaced to be read easily by literate
persons as well as by illiterate ones. That means putting spaces in
various places. Code can be variously compressed when it is intended to
be read only by machines.

It cannot be done that way. The character > must be converted to an
entity for HTML. That entity is "&gt;". To generate that entity, the
xml contains &amp;gt;.

I did not write that the copy'n'pasting must be in one move from tested
code to FAQ master. Elsewhere I have suggested doing the conversion by
pasting into a textarea and copying out of another. Manual
transcription or conversion is not trustworthy.

AFAIR, the conversion code that I use is sufficient (it handles itself)
but not necessarily optimised (who is/was IAS?) :

function SafeHTML(S) {
return S.split("&").join("&amp;").split("<").join("&lt;").
split(">").join("&gt;") } // IAS

One need only use that to translate from one textarea to another.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Mon, 15 Jun 2009 15:17:47, Garrett Smith


It does not; but it could. It could return {Bad:errortype, DS:string}.

Then one could use
formatDate(D).DS
if (formatDate(D).Bad) return
if (!(Z=formatDate(D)).Bad) S = Z.DS
etc.
depending on the circumstances of use.
If the Bad field amounts to true, the DS field could be missing, an
empty string, or a cautionary remark.




Ask someone to pen the date and time; then ask why they put a space
character rather than one needing ink; then listen to the consequent
aspersions on your intellect.

That is not an answer to the question.

You are getting rather like Thomas.

\u2415

I see Thomas seems to have taken the high road and not responded to you
dragged this into a flame war.

I acknowledged your unusual knowledge of dates. I cannot see why my
asking you a question about something you know a lot about would upset you.

I want to know which formats are most understood by humans, worldwide.
That is an essential part of the problem here. In my own casual
research, I asked some friends/acquaintances of mine who speak very
little English to participate. I explained that I was trying learn about
how different cultures read dates that are used for computers. I wrote
down, on paper:

Written: "2001-10-11"
Inberviewee: "Year" (points to year), "Month" (points to month) "Day"
(points to date).

Interviewer (me): "2001-10-11T10:23:11"
Inberviewee: "Two thousand, one; October; 11; Time: Ten hour, twenty
three minute, 11 second."

They got it. The only failed test was using a date with year "0768" with
a YYYY-MM-DD format. The fact that the year was < 1000 was the problem,
but that guy got the date with the "T" in it.

= ISO 8601 date/time formats are language-independent and
= unambiguous world-wide; and, for years 0000-9999, of constant
= lengths and sortable as strings. Its Extended format for common date
= is YYYY-MM-DD, and for time is hh:mm:ss.

The first sentence is too long.

ISO 8601 does not allow replacing T with whitespace. Section 3.4.1:
| Unless explicitly allowed by this International Standard the character
| “space” shall not be used in the representations

OTOH, RFC 3339 (2002) does allow T to be replaced with a space. Section
5.6 of that:
| NOTE: ISO 8601 defines date and time separated by "T".
| Applications using this syntax may choose, for the sake of
| readability, to specify a full-date and full-time separated by
| (say) a space character.


Revised outline:
[overview]
[common Extended formats]
[local offset]
[utc]
["T"]

Main entry for Dates:

| ISO 8601 defines date and time formats. Some benefits include:
| * language-independent and unambiguous world-wide.
| * sortable with a trivial string comparison.
| * easily readable and writable by software.
| * The basis for other standards, such as ISO 9075 and rfc 3339.
|
| The ISO Extended format for common date is YYYY-MM-DD, and for time is
| hh:mm:ss.
|
| For a local date/time offset from UTC, use YYYY-MM-DDThh:mm:ss±hh:mm.
|
| Never use a local date/time format for a non-local event. Instead, use
| UTC, as in YYYY-MM-DDThh:mm:ssZ (Z is the only letter suffix).
|
| The T can be omitted where that would not cause ambiguity. For
| rfc 3339 compliance, it may be replaced by a space and for SQL,
| it *must* be replaced by a single space.

NB. Does not mention about writing dates with words. Should have at
least a mention. For example:-

| For formatting dates to words, see: _url_.

Garrett

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 17 Jun 2009 00:54:36, Garrett Smith

In my own casual research, I asked some friends/acquaintances of mine
who speak very little English to participate.

They'll understand such dates. Try asking Americans, who know very
little international.

ISO 8601 does not allow replacing T with whitespace. Section 3.4.1:
| Unless explicitly allowed by this International Standard the character
| “space†shall not be used in the representations

Read on to 4.3.2, containing

NOTE By mutual agreement of the partners in information interchange,
the character [T] may be omitted in applications where there is no
risk of confusing a date and time of day representation with others
defined in this International Standard.

Disregard SQL and others; they have their own standards which may be
ISO-like and clearly need to be complied with. Consider date/times for
use within the current script and for interaction with the user.

* One can use the "T" format, which is not quite as easy to read because
of the lack of whitespace between the two parts.

* One can omit the "T", which is silly in Extended.

* One can replace the "T" with a space, taking the normal web-author
argument of power as equivalent to the agreement required by ISO (it's
much the same as using author-preferred border and font-family in the
FAQ).

* One can decide not to write the (date-and-time) in ISO, but to write
the date in ISO, followed by a space, followed by the time in ISO.

If there is some reason to require the date-and-time to be a single
lexical unit, use the "T". Otherwise, choose either the third or the
fourth above.

Main entry for Dates:

| ISO 8601 defines date and time formats. Some benefits include:
| * language-independent and unambiguous world-wide.
| * sortable with a trivial string comparison. by xxxxxxxxxxx
| * easily readable and writable by software.
| * The basis for other standards, such as ISO 9075 and rfc 3339.

Fix capitalisation and punctuation, and it will do. But it is not
euphonious; the last line jars. "The basis" should be more adjectival.

| The ISO Extended format for common date is YYYY-MM-DD, and for time is

^ full ^ local

| hh:mm:ss.

There "full" is a nod to not requiring :ss ; without an offset, the date
is local without indicating where.

| For a local date/time offset from UTC, use YYYY-MM-DDThh:mm:ss±hh:mm.

xxxxxx ^ with an
There, a location may be implied, but the overall value is UTC.

| Never use a local date/time format for a non-local event. Instead, use
| UTC, as in YYYY-MM-DDThh:mm:ssZ (Z is the only letter suffix).
|
| The T can be omitted where that would not cause ambiguity. For
| rfc 3339 compliance, it may be replaced by a space and for SQL,
| it *must* be replaced by a single space.

NB. Does not mention about writing dates with words. Should have at
least a mention. For example:-

| For formatting dates to words, see: _url_.

Or "numeric" in the heading. No need to discuss it here, because after
reading the numeric section, adding day-of-week or using month-as-word
should be obvious.

That is, provided that an example of declaring an array literal is added
to the FAQ (it could be a new section; it's been answered, if not asked,
often enough), for which month serves as an example. Could use day-of-
week 0 to 7 ["Sun", "Mon" ..."Sat", Sun"] to accommodate both JS/C and
ISO numbering. Ought to include an example "[, a, ... , z]" for when an
array 1 to N is needed.

 

[Garrett Smith]

Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Fri, 5 Jun 2009 09:17:04, Garrett Smith
<[email protected]> posted:
Garrett Smith wrote:
Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Wed, 3 Jun 2009 01:31:50, Garrett Smith
<[email protected]> posted:
[...]
* @throws {Error} if the year is < 0.

Correction:
| @throws {Error} if the year is not in range.

Is that a JSDoc used to document snippets in FAQ? I couldn't find a
mention of it anywhere on a page. Its keywords are quite
self-explanatory, of course, but wouldn't it make sense to give a link
to its official documentation?

It's actually JSDoc Toolkit there. It could be mentioned in the "Meta"
section.

| The code examples use _url:JSDoc Toolkit_ comments.

Your thoughts on handling the invalid date? Should it throw or return
the empty string as a return value?

Recent ES5 discussions on es-discuss mailing list[1] indicate that
Date.prototype.toISOString() will probably be designed to throw in that
case.

Garrett
[1]https://mail.mozilla.org/pipermail/es-discuss/2009-June/009495.html

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 17 Jun 2009 00:54:36, Garrett Smith


They'll understand such dates. Try asking Americans, who know very
little international.

When asked, each responded negatively; neither had seen that format. I
asked the second interviewee how he knew what "T" meant. He told me that
he assumed that "T" meant "Time". I concluded that he solved this by
intuition, and that the format, including "T", was intuitive to him.

Regarding the "ask Americans", I have, I may have mentioned in this or
another thread, that I have used the Extended YYYY-MM-DD format at the
doctors office forms where __/__/__ was provided on the form. I simply
struck a line thorugh that and wrote an ISO Extended YYYY-MM-DD above
it. Though I did not confirm, they did not ask for any clarification. If
clarification was needed, they had about a 30 minute window to ask.

Read on to 4.3.2, containing

Right, and "omitted" does not mean "replaced with something else."

NOTE By mutual agreement of the partners in information interchange,
the character [T] may be omitted in applications where there is no
risk of confusing a date and time of day representation with others
defined in this International Standard.

Disregard SQL and others; they have their own standards which may be
ISO-like and clearly need to be complied with. Consider date/times for
use within the current script and for interaction with the user.

The FAQ code itself is useful for derivative standard formats.

As you have seen in the jscript newsgroup, there are cases where
evidence of the existence such standards would be relavant. The poster
in that thread wrote:

| I have to write my software to work in the world as it exists today.

Mentioning other formats recitifies the misconception that ISO 8601 is a
"Europeoan format". RFC 3339 says its a practical standard that is used
on the web, for humans. ISO 9075 says its used in SQL.

A sentence and a link mentioning derivative standards should make that
obvious.

* One can use the "T" format, which is not quite as easy to read because
of the lack of whitespace between the two parts.

* One can omit the "T", which is silly in Extended.

* One can replace the "T" with a space, taking the normal web-author
argument of power as equivalent to the agreement required by ISO (it's
much the same as using author-preferred border and font-family in the
FAQ).

No, it is not the same. That date format is defined by ISO 8601. The
border of the root element is styling.

When this entry reaches a reasonable stopping point, I'll upload the new
version. No border on the root.

* One can decide not to write the (date-and-time) in ISO, but to write
the date in ISO, followed by a space, followed by the time in ISO.

Right. However, the statement "The T can be replaced with whitespace",
in the given context seems misleading. It could mislead the reader to
believing that that is a given allowance by ISO 8601. In fact, ISO 8601
does not allow replacing T with whitespace.

If there is some reason to require the date-and-time to be a single
lexical unit, use the "T". Otherwise, choose either the third or the
fourth above.





Fix capitalisation and punctuation, and it will do. But it is not
euphonious; the last line jars. "The basis" should be more adjectival.

Remove the full-stop on the list items. Those aren't sentences.

"The basis for" could be changed to:

"compatible with"

| * compatible with standards ISO 9075 and rfc 3339

Does that need qualifying? I want to avoid sounding as if ISO 8601
format came after those.

^ full ^ local
There "full" is a nod to not requiring :ss ; without an offset, the date
is local without indicating where.

xxxxxx ^ with an
There, a location may be implied, but the overall value is UTC.

"local event" seems more to the point.

Compare:
| For a date/time with an offset from UTC, use
| YYYY-MM-DDThh:mm:ss±hh:mm.

-or-

| For a local event with an offset from UTC, use
| YYYY-MM-DDThh:mm:ss±hh:mm.


[...]

Revised Draft:
| ISO 8601 defines date and time formats. Some benefits include:
| * language-independent and unambiguous world-wide
| * sortable with a trivial string comparison
| * easily readable and writable by software
| * compatible with standards ISO 9075 and rfc 3339
|
| The ISO Extended format for common date is YYYY-MM-DD, and for time is
| hh:mm:ss.
|
| For a local event with an offset from UTC, use
| YYYY-MM-DDThh:mm:ss±hh:mm.
|
| The T can be omitted where that would not cause ambiguity. For
| rfc 3339 compliance, it may be replaced by a space and for SQL,
| it *must* be replaced by a single space.

Well?

Or "numeric" in the heading. No need to discuss it here, because after
reading the numeric section, adding day-of-week or using month-as-word
should be obvious.

Not necessarily. That day and month names need l10n, and so does the
order and symbols associated therewith. This requires server processing.
Such discussion ought to mention cldr.

That is, provided that an example of declaring an array literal is added
to the FAQ (it could be a new section; it's been answered, if not asked,
often enough), for which month serves as an example. Could use day-of-
week 0 to 7 ["Sun", "Mon" ..."Sat", Sun"] to accommodate both JS/C and
ISO numbering. Ought to include an example "[, a, ... , z]" for when an
array 1 to N is needed.

A section on Arrays would be valuable to the FAQ.

The size of the FAQ may seem intimidating. To mitigate that, its
document presentation can be improved.

Garrett

 

[Garrett Smith]

[...]

have to write my software to work in the world as it exists today.

Mentioning other formats recitifies the misconception that ISO 8601 is a

rectifies that the misconception that ISO 8601 is a misconception.

[...]

Garrett

 

[Garrett Smith]

[...]

have to write my software to work in the world as it exists today.

Mentioning other formats recitifies the misconception that ISO 8601 is a

rectifies that the misconception that ISO 8601 is a misconception.

That didn't express what I wanted either.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Thu, 18 Jun 2009 11:42:01, Garrett Smith

Dr J R Stockton wrote:

Mentioning other formats recitifies the misconception that ISO 8601 is
a "Europeoan format".

Explainable by realising that the I in ISO means "International" (AISB)
and that too many Americans think that "International" means "not us".

RFC 3339 says its a practical standard that is used on the web, for
humans. ISO 9075 says its used in SQL.

RFC 3339 does not say that. It talks about human readability, which is
a potential; it does not cite any actual usage. Web pages, including
mine, contain dates matching RFC 3339 5.6 - but that is not intentional;
it is a consequence of matching ISO 8601.

What RFC 3339 does, in effect, is to convert (parts of) an International
(i.e. non-American) standard into an Internet one, which US geeks do
consider potentially applicable to them.

No, it is not the same. That date format is defined by ISO 8601. The
border of the root element is styling.

It cannot be attempted to be believed that ISO mean that YYYY-MM-
DDhh:mm:ss is an acceptable alternative for YYYY-MM-DDThh:mm:ss; but the
former format is unambiguous, After introducing YYYY-MM-DDThh:mm:ss, one
should not go on to say that the T can be removed where ambiguity is not
caused - even if ISO did.

| * compatible with standards ISO 9075 and rfc 3339

Does that need qualifying? I want to avoid sounding as if ISO 8601
format came after those.

There is no point in mentioning RFC 3339. Laughably, dated July 2002,
it says "This information is based on the 1988 version of ISO 8601.
There may be some changes in the 2000 revision.". It's just a rehash of
a subset of ISO 8601 - and I know that the authors did not properly test
at least one testable aspect of it.

Where a standard is cited by number in the FAQ, its title should be
given or represented; e.g. "(SQL)" could suffice.

Revised Draft:
| ISO 8601 defines date and time formats. Some benefits include:
| * language-independent and unambiguous world-wide
| * sortable with a trivial string comparison xxxxxxxxxxxxxx ^by
| * easily readable and writable by software
| * compatible with standards ISO 9075 and rfc 3339

RFC
The previous sentence lacks a full stop. Be aware that HTML seems not
to allow lists in paragraphs. There is no need for a formal list there;
this is not a PowerPoint presentation.

| For a local event with an offset from UTC, use
| YYYY-MM-DDThh:mm:ss±hh:mm.

That misses the point. For a local event, one does not need an offset
indication, unless the local area includes a time offset boundary. That
form is used to give a local date/time that can be understood exactly
outside the local area.

That day and month names need l10n, and so does the ???? <- jargon
order and symbols associated therewith. This requires server
processing. Such discussion ought to mention cldr.

???? <- jargon

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Thu, 18 Jun 2009 11:42:01, Garrett Smith



Explainable by realising that the I in ISO means "International" (AISB)
and that too many Americans think that "International" means "not us".

Possibly not just Americans. A man from India recently informed me the
the format I wrote was European after presenting a form with an Extended
Date Format.

That sentence was to be taken with the previous sentence.

RFC 3339 is "Date and Time on the Internet". The existence of RFC 3339
means that there is a format that is intended for use on the web.

RFC 3339 does not say that. It talks about human readability, which is
a potential; it does not cite any actual usage. Web pages, including
mine, contain dates matching RFC 3339 5.6 - but that is not intentional;
it is a consequence of matching ISO 8601.

What RFC 3339 does, in effect, is to convert (parts of) an International
(i.e. non-American) standard into an Internet one, which US geeks do
consider potentially applicable to them.

RFC 3339 defines a profile of ISO 8601 for use in Internet protocols. It
is a conformant subset of the ISO 8601 extended format.

"US Geeks" sounds like yet another disparaging remark towards Americans.
Such remarks are counterproductive detract from the thread.

It cannot be attempted to be believed that ISO mean that YYYY-MM-
DDhh:mm:ss is an acceptable alternative for YYYY-MM-DDThh:mm:ss; but the
former format is unambiguous, After introducing YYYY-MM-DDThh:mm:ss, one
should not go on to say that the T can be removed where ambiguity is not
caused - even if ISO did.

Sorry, I didn't quite get that.

There is no point in mentioning RFC 3339. Laughably, dated July 2002,
it says "This information is based on the 1988 version of ISO 8601.
There may be some changes in the 2000 revision.". It's just a rehash of
a subset of ISO 8601 - and I know that the authors did not properly test
at least one testable aspect of it.

The existence of RFC 3339 gives credence that Extended Date format is of
practical use and recommended for humans to read. That format is not, as
some might think, academic, and not, as others may feel, for machine-use
only.

RFC 3339 is not obsoleted by a more recent standard. Were that the case,
the more recent standard would be under consideration.

Where a standard is cited by number in the FAQ, its title should be
given or represented; e.g. "(SQL)" could suffice.



xxxxxxxxxxxxxx ^by
OK.

RFC
The previous sentence lacks a full stop. Be aware that HTML seems not
to allow lists in paragraphs. There is no need for a formal list there;
this is not a PowerPoint presentation.

The list makes it easier to read.

Either every list item is a sentence, or none of them are.

A list item gets a punctuation mark when it forms a sentence. I prefer
consistency with lists - either all items are sentences or no items are
sentences.

This list has no punctuation marks.

That misses the point. For a local event, one does not need an offset
indication, unless the local area includes a time offset boundary. That
form is used to give a local date/time that can be understood exactly
outside the local area.

Right.

For an event with an offset from UTC, use YYYY-MM-DDThh:mm:ss±hh:mm.

???? <- jargon
http://google.com/search?q=l10n
http://en.wikipedia.org/wiki/Internationalization_and_localization


???? <- jargon

It has come up before, and I remember some more nationalist views being
posted on that thread. Please search the archives and please also see:

http://google.com/search?q=cldr
cldr.unicode.org

Garrett

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Fri, 19 Jun 2009 16:15:12, Garrett Smith

Possibly not just Americans. A man from India recently informed me the
the format I wrote was European after presenting a form with an
Extended Date Format.

In India, it seems that D M Y order is commonly used, and Y M D is as
yet not. An Indian of the travelling classes would know that the US
uses M D Y. Clearly he recognised the superiority of Y M D and
naturally assumed that, as it was not Indian, it must be European.

RFC 3339 is "Date and Time on the Internet". The existence of RFC 3339
means that there is a format that is intended for use on the web.

I doubt whether it means that; "Web" is not included, and "www" only
once, in the URL of an ITU page. It does say "for use in Internet
protocols". |||| Internet protocols should use a seconds count from
1970.0, with offset from GMT parenthetically. Only a small fraction of
instances are ever read by humans; and, when a computer displays them,
it can use the reader's preferred format. ||||

"US Geeks" sounds like yet another disparaging remark towards
Americans. Such remarks are counterproductive detract from the thread.

Disparagement is aimed at where it is deserved.

Sorry, I didn't quite get that.

Consider whether you wish to support use of YYYY-MM-DDhh:mm:ss .

The list makes it easier to read.

This list has no punctuation marks.

The previous sentence, as written, is "Some benefits include:".
And one of "some", "include" is superfluous.

For an event with an offset from UTC, use YYYY-MM-DDThh:mm:ss±hh:mm.


http://google.com/search?q=l10n

How very silly. Eschew.

It has come up before, and I remember some more nationalist views being
posted on that thread. Please search the archives and please also see:

http://google.com/search?q=cldr

Should be CLDR.



You continue to show a tendency towards esoterica, which have no place
in a FAQ intended to assist newcomers. For showing off geeky knowledge,
you should combine forces with DM & TL, and do it elsewhere.