#4850 closed defect (fixed)
DateTextBox fills with NaN for years like 0050 (IE only)
Reported by: | guest | Owned by: | Adam Peller |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Dijit - Form | Version: | 0.9 |
Keywords: | DateTextBox NaN | Cc: | [email protected]…, [email protected]… |
Blocked By: | Blocking: |
Description
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.
Attachments (3)
Change History (19)
comment:1 Changed 14 years ago by
comment:3 Changed 13 years ago by
Milestone: | → 1.1 |
---|
comment:4 Changed 13 years ago by
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.
Changed 13 years ago by
Attachment: | calendar_ie_nan.diff added |
---|
Use new Date(Number(dateObject)) in _Calendar.js
comment:5 Changed 13 years ago by
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())
comment:6 Changed 13 years ago by
Owner: | changed from Douglas Hays to Adam Peller |
---|
comment:8 Changed 13 years ago by
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
Changed 13 years ago by
Attachment: | dojo-years-under-1000.patch added |
---|
Handle dates with years less than 1000 in dojo.date.
Changed 13 years ago by
Attachment: | dijit-years-under-1000.patch added |
---|
Handle dates with years less than 1000 in dijit._Calendar
comment:9 Changed 13 years ago by
comment:10 Changed 13 years ago by
Cc: | [email protected]… added |
---|
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
comment:11 Changed 13 years ago by
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; }
comment:12 Changed 13 years ago by
Thomas, isn't the setFullYear only an issue for years < 100? Also, why do we need to pad 'year only' formatting to 4 digits?
comment:13 Changed 13 years ago by
comment:14 Changed 13 years ago by
comment:15 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:16 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
(In [11043]) refs #4850 - random cleanups and shrinkage.