Ticket #2531809 (closed defect)
ReporterMattias Thorslund |
Opened: 02/23/12 Last modified: 03/30/12 Status: closed Type: defect Resolution: wontfix |
Owner Allen Rabinovich |
Target Release: Priority: P3 (normal) |
|---|---|---|---|
| Summary: | Date validation with Y.DataType.Date.isValidDate defeated by Y.DataType.Date.parse | ||
| Description: | I'm trying to validate input as a date, using the Y.DataType.Date.parse() function and isValidDate(). My trouble is that in Firefox, Date.parse() accepts values that I believe should be considered var d = Y.DataType.Date.parse('1/19/2012 112:011'); //note the time
Similarly, entering invalid dates like February 31st of March 33rd simply returns a valid Date object. If I understand correctly, Y.DataType.Date.parse passes the date parsing on to the browser natively (the above from Firefox 10.0.1; Webkit works as I'd expect). Since FF is considerably more lax in |
||
| Type: | defect | Observed in Version: | 3.4.1 |
| Component: | DataType-Date | Severity: | S3 (normal) |
| Assigned To: | Allen Rabinovich | Target Release: | |
| Location: | Priority: | P3 (normal) | |
| Tags: | validation date | Relates To: | |
| Browsers: | Firefox - Latest | ||
| URL: | |||
| Test Information: | |||
Change History
|
Posted: 03/30/12
|
parse will probably be deprecated in 3.6 -- it's a pretty useless method because it basically passes info to the Date() constructor.
The isValidDate behaves correctly in all cases. Different browsers construct Date differently, often interpreting out-of-bounds value assignments as that many units over the limit (so interpreting the "33rd" of the month as the "2nd" of the next month, if the preceding month had 31 days). They then return a valid Date object -- and isValidDate will report it as valid. If a non-date is passed in, it will return false.
So, parse() is problematic -- mostly because of its uselessness and should be deprecated. isValidDate does not need to be fixed. Reopen if you disagree.