-
Notifications
You must be signed in to change notification settings - Fork 603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extra characters tolerated in dateParse and numberParse #492
Comments
Any thoughts on this? Thanks. |
I will definitely consider pull requests making the parser less permissive. For the date parser, you may want to check the date/tokenizer-properties.js and the date/tokenizer.js. For number parser, you may want to check #353. |
Closing this issue since this isn't a bug [1]. This can still be used to discuss any API change for the optional less permissive parsing. PRs welcome. 1: JavaScript has similar behavior in what's regard extra characters tolerated in some situations. > parseFloat('123 asd')
123
> parseFloat('asd 123')
// NaN |
Update CHANGELOG.md
- Correctly handles prefix and suffix literals; #353; - Loose Matching: This implementation is now much closer to UTS#35 7.1.2 Loose Matching http://unicode.org/reports/tr35/#Loose_Matching and fixes all reported cases that related to it, including #288; - Regression: Drop scientific notation parsing support, which wasn't documented anyway and shall be implemented by #533. Ref #292 Fixes #353 Fixes #46 Fixes #288 Fixes #443 Fixes #457 Fixes #492 Fixes #587 Fixes #644
- Correctly handles prefix and suffix literals; #353; - Loose Matching: This implementation is now much closer to UTS#35 7.1.2 Loose Matching http://unicode.org/reports/tr35/#Loose_Matching and fixes all reported cases that are related to it, including #288; - Regression: Drop scientific notation parsing support, which wasn't documented anyway and shall be implemented by #533. Ref #292 Fixes #353 Fixes #46 Fixes #288 Fixes #443 Fixes #457 Fixes #492 Fixes #587 Fixes #644
- Correctly handles prefix and suffix literals; #353; - Loose Matching: This implementation is now much closer to UTS#35 7.1.2 Loose Matching http://unicode.org/reports/tr35/#Loose_Matching and fixes all reported cases that are related to it, including #288; - Regression: Drop scientific notation parsing support, which wasn't documented anyway and shall be implemented by #533. Ref #292 Fixes #353 Fixes #46 Fixes #288 Fixes #443 Fixes #457 Fixes #492 Fixes #587 Fixes #644
- Correctly handles prefix and suffix literals; #353; - Loose Matching: This implementation is now much closer to UTS#35 7.1.2 Loose Matching http://unicode.org/reports/tr35/#Loose_Matching and fixes all reported cases that are related to it, including #288; - Regression: Drop scientific notation parsing support, which wasn't documented anyway and shall be implemented by #533. Ref #292 Fixes #353 Fixes #46 Fixes #288 Fixes #443 Fixes #457 Fixes #492 Fixes #587 Fixes #644
Using 1.0.0. It seems that gibberish input is getting parsed instead of returning null/NaN.
locale = "pt_BR";
value = "12:12 am sdfsdf33dfllsdf lll;;lk";
Globalize(locale).dateParser({time:"short"})(value)
=> Wed Aug 26 2015 12:12:00 GMT-0500 (CDT)
How is this valid?
Similarly,
locale = "en";
value = "123123 sdfsdf;;dfllsdf";
Globalize(locale).numberParser()(value)
=> 123123
Shouldn't Globalize object to this sort of input??
The text was updated successfully, but these errors were encountered: