Skip to content
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

Closed
alienintheheights opened this issue Aug 26, 2015 · 3 comments · Fixed by #656
Closed

Extra characters tolerated in dateParse and numberParse #492

alienintheheights opened this issue Aug 26, 2015 · 3 comments · Fixed by #656

Comments

@alienintheheights
Copy link

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??

@alienintheheights
Copy link
Author

Any thoughts on this? Thanks.

@rxaviers
Copy link
Member

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.

@rxaviers rxaviers mentioned this issue Oct 10, 2015
6 tasks
@rxaviers
Copy link
Member

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

ashensis pushed a commit to ashensis/globalize that referenced this issue Mar 17, 2016
rxaviers added a commit that referenced this issue Nov 28, 2016
- 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
rxaviers added a commit that referenced this issue Nov 28, 2016
- 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
rxaviers added a commit that referenced this issue Dec 13, 2016
- 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
rxaviers added a commit that referenced this issue Dec 13, 2016
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants