-
Notifications
You must be signed in to change notification settings - Fork 6.7k
fix(dateparser): add type and validity check #3759
fix(dateparser): add type and validity check #3759
Conversation
Leaving a comment to keep track on this one. Will review this saturday. |
@wesleycho , there's a lot of whitespace changes in this PR. Any chance of editing that away? Just want to avoid adding noise to git blame. |
Code change looks good to me. |
Sure, I can do that sometime later today or tomorrow. I can add a $log.debug or $log.warn statement about a string where isNaN returns true and falling back to date constructor. |
afe69ca
to
1fd0b80
Compare
I reverted all code style changes |
09919d0
to
b59efc1
Compare
@@ -136,6 +136,9 @@ angular.module('ui.bootstrap.dateparser', []) | |||
milliseconds: baseDate.getMilliseconds() | |||
}; | |||
} else { | |||
if (baseDate) { | |||
$log.warn('dateparser:', 'baseDate is a string with no date representation'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about baseDate is not a valid date
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much better than what I had - changing shortly
- Add type and validity check to ensure proper date object is created - Make code style uniform in scripts chore(dateparser): revert code style changes chore(dateparser): add `$log.warn`
b59efc1
to
3dbfb80
Compare
Hm, I was just testing this, I think this introduces another bug, now there's time added to the string, possibly due to a toISOString conversion that shouldn't be done: See http://plnkr.co/edit/XCvfhGTYUUraB6mTSVSK?p=preview (there are steps to reproduce on the Plunker) I'm thinking the change in #3294 is needed to actually fix this at the root. |
I tried some experimenting, and it looks like stripping out the |
#3643 may also be related. |
+1 |
Hi, don't understand this check:
if baseDate is date getTime always will return an number, right? |
That is not true - try doing |
Yep, you right, Thank you for example. |
@chrisirhc what are your thoughts on this? I do not think that the model aspect is fixable, since the model value will always become a date object or This can potentially be alleviated if we are able to switch to allowing users to bring in a custom parser & formatter for converting between a user desired model and the view value, which would also open up moment.js support for users, but that is a large & separate task. I think this PR should make it in in its current incarnation though - it fixes a badly breaking bug in the datepicker. |
@wesleycho please remove || new Date(...) "fallback" that actually introducing new bugs. |
That is a breaking change that has explicit tests written against it - it is outside the scope of this PR. |
Is this in any way related to Issue #3617? Reason I ask is because one of the behaviors of the bug illustrated in 3617 is that when you clear a datepicker field, it sets a form's $invalid property to false, even though the field is blank and the field is marked as not required. I created a plunker illustrating the issue and is posted in that thread. |
Partially related. |
@llafuente I am not seeing the form being invalid incorrectly - here is an updated Plunker. |
This patch alone do not solve: #3617 I apply this patch to 0.13, and didn't work, form was $invalid. |
|
Merging this in shortly, as this check in itself is completely safe & necessary. |
Plunker with fix in action here
This addresses #3713