In comp.lang.javascript message <
[email protected]
september.org>, Thu, 11 Jun 2009 09:13:27, Garrett Smith
Dr J R Stockton wrote:
"throw" is a common flow-of-control term in programming. It could be
listed in the glossary, if such thing is to be created.
That does not mean that the FAQ reader will know what the effect of
throw Error("year must be 0000-9999");
will be in all browsers and all settings.
IMHO, reserved words in computer languages should not be common words in
common natural languages, since that makes it hard to search for the
reserved word itself. Bring back the KDF9, where IIRC reserved words
all started with "!" and could be abbreviated once unique with "." - the
compiler would understand "!fun." and the editor could auto-expand it to
"!function".
Perhaps SAM or others could help there; if there is a good
JavaScript text - not the standard - on-line in French, it could
be searched for "throw" and one would find only the reserved
word proper, avoiding instances of the verb "jeter".
Using "alert" would be better; one knows what it will do, and it's an
obvious candidate for replacement if unsuited to circumstances.
Consider it as a place-holder for whatever suits the application.
An invalid date keeps the code a tiny bit smaller. It is like returning
null however, the returned object is a Date, so it does not require a
null check.
AFAIK, there is only one "invalid" value that a Date Object
can have, NaN. If it is used, there should be a warning that
new Date(NaN).toString() is browser-dependent.
FWIW, here new Date(NaN) is slower than new Date(0) in FF but not IE.
^ ^ Omit; add " ..." or " { ... }".
| Yes; but more readable with a space there
If I am going to go with that, I can also use regexp.exec(
dateStringInRange ) to avoid error.
Don't know whether/why 'exec' is the best method of RegExp or String to
use there. But it may well be.
I don't quite understand your testing methodology. It sounds like it
would require changing the computer's time zone. Did it get that right?
Either that or using consultants elsewhere. We have readers in
positive, zero, and negative northern zones, and at least a positive
southern one. But you don't mean time zone, you mean offset; AFAIK, no-
one here currently has LCT = UTC.
NaN should generate an invalid date in any time zone, so what you
wanted to test would not apply here, right?
Yes, but I've not tested that. But NaN is a valid date in JavaScript,
one which is off-calendar. It should not lightly be called invalid.
I can't recommend relying on undocumented implementation extensions.
To be consistent, you'll have to avoid new Date("1/20/2009") for the
Inauguration.
Anyone relying on the first release of any software is a fool; any
browser not accepting "2009/01/20" correctly on or after the second
release should never be trusted, because five major browsers accept it
(and I've never known them not to).
And you might have to avoid 'throw', since the Standard seems not to
define the actual effect seen (and if it does, it has to define it as
somewhat indeterminate, since browsers behave differently).
For a FAQ, it is only actual browser behaviour that matters, though it
would be wrong to recommend something definitely contrary to the
Standard. Where the Standard is silent, the facts can speak.
Taking all of the suggestions, the new draft follows:-
================================================================
4.1 How do I write and read a date with javascript?
The ISO 8601 Extended format can be understood internationally, without
xxx ^An (there are more than one) (don't use Any[0])
world-wide ---> xxxxxxxxxxxxxx
ambiguity.
A local Date object where year >= 0 can be formatted to a common ISO xxxxx with?
8601 format YYYY-MM-DD with:-
/** Formats a Date to YYYY-MM-DD, compatible with both ^ (local time)
* ISO 8601 and ISO/IEC 9075-2:2003 (E) (SQL 'date' type).
* @param {Date} dateInRange year 0000 to 9999.
* @throws {Error} if the year is < 0.
*/
function formatDate(dateInRange) {
var year = dateInRange.getFullYear(),
isInRange = year > 0 && year < 9999,
yyyy, mm, dd;
if(!isInRange ) {
throw Error("year must be 0000-9999");
You cannot guarantee that to be the only throw of that string in the
page; "formatDate : year must be 0000-9999" could be better.
}
yyyy = padLeft(year, 4, "0");
mm = padLeft(dateInRange.getMonth() + 1, 2, "0");
dd = padLeft(dateInRange.getDate(), 2, "0");
return yyyy + "-" + mm + "-" + dd;
}
I see no need to have both yyyy & year. Entia non sunt multiplicanda
praeter necessitatem.
/**
* @param {string} input: input value converted to string.
* @param {number} size: desired length of output.
* @param {string} ch: single character to prefix to s.
*/
function padLeft(input, size, ch) {
var s = input + "";
or input += "" and consequential changes
while (s.length < size) {
s = ch + s;
}
return s;
}
Never use a local date/time for a non-local event. Instead, use UTC, as
in ISO 8601 YYYY-MM-DDThh:mm:ssZ ( Z is the only letter suffix). ?? postfix ??
The T may be omitted where doing so would not cause ambiguity. For an
SQL date, it must be replaced by a single space.
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.
An Extended ISO 8601 Date format YYYY-MM-DD can be parsed to a local
A local date in Extended ISO 8601 format YYYY-MM-DD can be read to a
Date with the following:-
Date Object with the following:-
* @return {Date} Native Date object representing the string.
Can you promise that the Native one has not been superseded?
function parseISO8601( dateStringInRange ) {
var date = new Date(NaN),
isoExp, parts;
isoExp = /^\s*([\d]{4})-(0[1-9]|1[0-2])-([0-2][0-9]|(?:3[0|1]))\s*$/;
parts = isoExp.exec(dateStringInRange);
if(parts) {
date.setFullYear(parts[1], parts[2] - 1, parts[3]);
date.setHours(0,0,0,0);
With new Date(NaN), setFullYear cannot avoid setting the "local time
part"; therefore, setHours may not now be essential.
}
return date;
}
See also:
* ECMA-262 Date.prototype, s. 15.9.4.2 15.9
*
http://en.wikipedia.org/wiki/ISO_8601
* ISO 8601:2004(E)
*
http://www.merlyn.demon.co.uk/js-date9.htm
The RegExp is not acceptable. It partly but incompletely validates the
date. The date should be either tested for character pattern or not so
tested; and it should either be fully numerically validated or not
numerically validated at all.
Again, the answers are all in the archives[1], and Thomas seems to be
slipping since AFAIR he has not told you that.
Test the pattern for, at the very minimum,
/^\D*\d+\D+\d+\D+\d{1,2} then non-digit or end/.
Apply the three fields as above into new Date,
check the Month of the date object agrees with the second numeric field.
Note : I know that RegExp pattern is more liberal than ISO 8601.
Note : RegExp for non-extended can be given; /^\s+-?\d{4,}-\d\d-\d\d ...
Note : I left the parentheses off, for simplicity.
With the Date2 Object, one piece of code like that should serve both for
local date and UTC date.
[0] Unwise to claim that ISO Week Numbering will be understood in NA.
[1] and on my site.
