DateTextBox fills with NaN for years like 0050 (IE only)

[guest]

Create a standard DateTextBox?. On IE, edit the year in the input field to 0050 and click off and back on. The calendar fills with NaN, and doesn't reset even when a correct date is reentered in the input field.

[dante]

(In [11043]) refs #4850 - random cleanups and shrinkage.

[bill]

Above checkin was for #4580.

[guest]

At least part of this problem is caused by IE not correctly handling new Date(dateObj) properly. A fix for this is to do new Date(Number(dateObj)) instead. Attaching a patch that does this for _Calendar.js.

[guest]

Use new Date(Number(dateObject)) in _Calendar.js

[guest]

Not totally sure this is related. With the above Number() fix in combination with a datePattern='mm/dd/yyyy', typing in 12/12/05 gets you 12/12/0005 in the text entry and 1905 in the calendar popup.

• Thomas E Jenkins (who also posted the above Number())

[guest]

Of the same nature as issue #3112 fixed in [8721]

[guest]

There are a few parts to fix to have working years < 1000. When using the Date(year,month,day) constructor Javascript will round up any year argument less than 4 digits.

new Date(0001,10,10) == Nov 10th, 1901

d = new Date();
d.setFullYear(0001,10,10) == Nov 10th, 0001

I will attach two patches one for dijit and one for dojo. This includes the above new Date(Number(dateObject)) workaround as well. These patches contain:

• use setFullYear() in dojo.date.stamp.fromISOString()
• use new Date(Number(dateObject)) in dijit._Calendar
• use setFullYear() when setting Year label in dijit._Calendar
• pad to 4 return value of dojo.date.locale.format when using undocumented selector:"year"

It's possible there are more Date constructor related issues around.

I'd love to have [email protected]… added to the CC.

Thomas E Jenkins

[guest]

Handle dates with years less than 1000 in dojo.date.

[guest]

Handle dates with years less than 1000 in dijit._Calendar

[Adam Peller]

(In [12084]) Treat 2 year dates as 4 year dates, regardless of the pattern for strict=false. Refs #4850

[Adam Peller]

Thanks, Thomas, for the patches. I'm a little nervous about adding more Date setters/constructors to the code as they're slow, but we'll look into it. It's tempting to just say no support for dates < 100CE

[Douglas Hays]

Could change dojo.date.locale.parse from:

if(!valid ||
        (allTokens.indexOf('y') != -1 && dateObject.getFullYear() != result[0]) ||
        (allTokens.indexOf('M') != -1 && dateObject.getMonth() != result[1]) ||
        (allTokens.indexOf('d') != -1 && dateObject.getDate() != result[2])){
        return null;
}

to

dateObject.setFullYear(result[0]);//this is always set to the full year
if(!valid ||
        (allTokens.indexOf('M') != -1 && dateObject.getMonth() != result[1]) ||
        (allTokens.indexOf('d') != -1 && dateObject.getDate() != result[2])){
        return null;
}

[Adam Peller]

Thomas, isn't the setFullYear only an issue for years < 100? Also, why do we need to pad 'year only' formatting to 4 digits?

[Adam Peller]

(In [12270]) Unnecessary to check year overflow in parse. Refs #4850

[Adam Peller]

(In [12820]) Fix strict mode checking of year < 100CE in dojo.date.parse. Refs #4850. Also remove unsupported whitespace tests and invalid 'es' locale tests. Fixes #5885

[Adam Peller]

not going to support years < 100CE in dojo.date.stamp for performance reasons (though the code is there commented out if someone really, really wants it) and I don't think it's necessary to pad the year in locale. Otherwise, hopefully everything here has been addressed.