To FootGlobal function parseInt should generally be given a second argument, an integer in the range 2 to 36, to set the input base for the string - parseInt("string", radix). If radix is undefined, null, zero, NaN, or missing, the base of the string is determined by its content. That may lead to error.
The string argument is case-independent. Leading whitespace is ignored. A optional leading sign, + or -, is then accepted. If a valid digit does not come next, NaN is returned
If the base is not set by a radix argument, leading 0X indicates hexadecimal. Otherwise, leading zero indicates either octal or decimal - octal is common, decimal is theoretically preferred and sometimes seen. Otherwise, the input is read as decimal. Digits (at least one) are then read up to the first character which cannot be part of a number in the selected base, or the end of the string.
So parseInt("09") will commonly read octal and give Number 0, but may read decimal and give Number 9.
For details, see ISO/IEC 16262 Section 15.1.2.2.
To convert decimal digit strings without trailing non-whitespace, one can use unary plus (or minus) : +"09" gives Number 9; +"" gives Number 0. Leading whitespace is ignored, a sign is accepted. User-input decimal numbers should be format-checked by RegExp, after which they can safely converted to Number with unary plus.
Dates can be input from calendars or from drop-down lists; but the best way (fast input; small code) is generally to enter the date as a string. For world-wide use, call for the unambiguous ISO 8601 format YYYY-MM-DD.
Sometimes the string must be read into a Date Object; sometimes it only needs to be checked and can be used as a string, perhaps normalised.
There are three basic cases :-
• Validate fully for exact compliance, format and Y M D
• Liberal format, validate Y M D as being on-calendar
• Known good; just needs to be read into a Date Object
A human-entered date should be validated for Y M D being compatible with the common calendar, and for the result being compatible with the application. A machine-entered date probably need not be validated for Y M D, but validation for pattern may catch "did not mean to read that as a date" errors. If the pattern is known to be satisfactory, the split method can be used, but it is generally good to use a Regular Expression.
There is one easy way to get some typing errors to be corrected : after the date has been entered (i.e. onChange), cause its day-of-week to appear adjacent. The user will often know the day of week of the intended date, and most errors will change that.
HTML <input type=date> should become usable - but at present (Oct 2009) it only works in Opera, and that badly.
This code is not itself a FAQ recommendation; it is to show what can be provided.
See also JavaScript : Object DATE2..
Check that all of this is represented below.
It is not the business of a general purpose date-output routine to pay too much attention to the various preferences of specialised systems. It should heed, but need not be absolutely bound by, ISO 8601. And it should either support, or be readily adaptable to support, field orders other than Y M D and separators other than '-', since those may be required for display.
The prime purpose should be to support (proleptic Gregorian) YYYY-MM-DD for current years; all years in 1000-9999 are equally easy.
It should also support earlier years, 0-999, in 4-digit form. That reduces confusion between years (for example) 98 & 1998, 10 & 2010 - and those may unintentionally occur in Date Objects.
It should also support all possible Date Object internal values, including NaN and values outside ±864e13 (since such can be set in at least one browser).
And it should never, for any value that a Date object can (rightly or wrongly) contain, give a string which actually represents a non-corresponding date.
The following can be described (when using "" for the positive sign) as compliant with ISO 8601 for 0000-9999, with XML for 0001-9999, etc.
In most applications, there is no need to make allowance for years outside 1000 to 9999. The code for those extremes should be easily removable.
It is not the business of a general purpose routine to apply bounds, such as year range, to the date value. That is for the application to do, by a wrapper or otherwise, and the required bounds may vary within an application. If applying bounds, remember to test with an invalid date (NaN).
For some formats, the job can IN FUTURE be done by using or editing the output of the FUTURE method toISOString. Using that on the Web at present is just plain silly.
This code handles any Date Object value, and can easily be modified to give any likely form of numeric Gregorian date string.
The function Sign should be adapted to meet the circumstances. In particular, positive years may require "+", " ", or "". It and Math.abs will often not be needed. For this purpose, my general function LZ can be simplified to use just (n < 10 ? "0" : "") + n . If the year value will always be four-digit, the while and NaN statements are not needed. The string NaN could be space-padded.
It may be necessary to left-pad the string with spaces; and/or, rarely, to increase the "4".
Note that, as coded here, the routine can be called either as a function or as a method of a Date Object.
For at least years from 1000 to 9999, the format given will comply with various standards including ISO 8601. Outside that range, where standards can differ, adjustment may be required if compliance is wanted.
Setting [window.]status is a convenient way, in some browsers, of showing progress information in an available edge corner of a window. Some browsers have no status bar; and some may be set to prevent scripts writing to it.
Status can be displayed in an element of the document; but during a continuous process the change will in some browsers not appear visibly. Then one can break the process into short sections, separated by a brief time-out.
Due to differences between browsers, it may be well to display status in more than one way.