Dr said:
In comp.lang.javascript message <
[email protected]
september.org>, Sat, 24 Oct 2009 01:12:30, Garrett Smith
PLEASE TRIM YOUR QUOTES
Better to include too much than trim too much.
I'm including the following remainder, to show how trimming too much
can lead to confusion.
You have confused matters by introducing Date Object to String in a
thread about FAQ "How can I create a Date from a String? (2009-10-05)" -
and you seem to have confused yourself.
You lost me there.
You trimmed far too much context, creating a hard-to-follow reply that
lacks context.
Since ISO 8601 only handles calendar dates, it naturally has no
representation for representing (for example) the object given by
new Date("2007:11:22"). Therefore the result of such test should not be
a valid ISO 8601 date - or anything like it.
Test? What test?
Code presuming the Object to represent a date in 0000-9999 would
probably give 0NaN-0NaN-0NaN or 0NaN-NaN-NaN.
Huh?
Slightly better code
would give NaN-NaN-NaN. "NaN", " NaN", or "Invalid Date" would be
satisfactory. Doing a throw is not a good solution; firstly, an end
user may not realise what is happening, and secondly, continuing may
provide more clues for the tester about what the real problem is.
Start over. Take a nap, get some coffee, whatever you need to do.
Not guaranteed.
I don't understand what that was written for.
The conversation seems to have degraded quite a bit.
My response above, was to show that your "NaN" string is going to be
as valid for Date.parse, in Tracemonkey as the result of -
aDate.toISOString() -.
Date.parse is specified to read the result of toISOString. Instead, it
is unrecognized in Firefox, and the result is the same as with NaN.
| 15.9.4.2 Date.parse (string)
| The parse function applies the ToString operator to its argument
| and interprets the resulting String as a date and time; it
| returns a Number, the UTC time value corresponding to the date
| and time. The String may be interpreted as a local time, a UTC
| time, or a time in some other time zone, depending on the
| contents of the String. The function first attempts to parse the
| format of the String according to the rules called out in Date
| Time String Format (15.9.1.15). If the String does not conform
| to that format the function may fall back to any implementation-
| specific heuristics or implementation-specific date formats.
| Unrecognizable Strings or dates containing illegal element
| values in the format String shall cause Date.parse to return
| NaN.
|
| If x is any Date object whose milliseconds amount is zero within
| a particular implementation of ECMAScript, then all of the
| following expressions should produce the same numeric value in
| that implementation, if all the properties referenced have their
| initial values:
|
| x.valueOf()
| Date.parse(x.toString())
| Date.parse(x.toUTCString())
| Date.parse(x.toISOString())
The answer to the question: "4.2 How can I create a Date from a String"
could, ideally be changed so that it uses Date.parse, where supported.
Then again, Date.parse is guaranteed by ES5 to parse the result from
toISOString, and *not* the most common format, so
Date.parse("2000-12-12")
- could return NaN. Pitiful.
As you know, I have many pages. You need not give the full URL, but
you should give the file name and maybe an anchor. If you mean as was
in <js-faq-u.htm>, the intention was to indicate only a preferred field
order.
Lets do tha for now. Link to Merlyn, provide an example for YYYY-MM-DD.
We can always revisit this for the FAQ, and what is done so far is at
least a meager improvement.
No. It is only necessary to say something like "For years 0000-9999,
that complies with ISO 9601; for 0001-9999, with SQL", after the code
and before the links you mention below.
Have you verfified that statement with the SQL standard, or did you mean
to write "XML Schema" instead of "SQL"?
That is of course wrong. YYYY-MM-DD is only the most common of six
equally standard forms for dates on 0000-9999, and the year range is
infinitely extendible.
Lets revisit that soon on the FAQ. Expanded range has teh benefit of
leveraging native toISOString().split("T")[0].
The benefit to using that "international standard" is that it is easier
to explain and understand, than YYYY+ type of format.
One should present the most widely useful code, and explain it with
sufficient skill. Little explanation is actually needed, because the
FAQ user can read and test the code.
The benefit to using extended range is that it can utilize the native
toISOString method:-
// Where supported
(new Date).toISOString().split("T")[0];
And where not supported, can use a fallback.
In which case there is no benefit in trying to use toISOString, except
in special cases where the possible gain in speed is perceptible. There
is no need to confuse date-to-string by including feature detection.
The design could be a bit different.
if(!Date.prototype.toISOString) { /* hand-rolled */ }
Then, where needed:-
var isoDateString = aDate.toISOString().split("T")[0];
- - - - -
Given that the FAQ is published in HTML to users expected to have
JavaScript, and that it is also published in a plain text rendering
approximating to what a browser reading the HTML will show : might it be
practical for the HTML version to have, where useful, a control of some
sort that brings additionally into view the reasoning behind the FAQ
recommendation.
I'd rather have test questions.
click for answer.
[user thinking...]
click...
[answer pops out]
Sorry, I don't understand that.
<js-faq-u.htm#GDF> green box contains something like such reasoning.
I see.
