Skip to content

fix(DatePipe): parse string input ourselves to avoid inconsistency between browsers - #13895

Closed
DzmitryShylovich wants to merge 2 commits into
angular:masterfrom
DzmitryShylovich:gh/13874
Closed

DzmitryShylovich wants to merge 2 commits into
angular:masterfrom
DzmitryShylovich:gh/13874

Conversation

@DzmitryShylovich

@DzmitryShylovich DzmitryShylovich commented Jan 12, 2017 •

Copy link
Copy Markdown
Contributor

Closes #12334 and #13874

Implementation from ng1

@intellix

intellix commented Jan 12, 2017 •

Copy link
Copy Markdown

Sweet, now I don't need moment to fix ONLY Safari

@vicb vicb added area: i18n Issues related to localization and internationalization action: review The PR is still awaiting reviews from at least one requested reviewer labels Jan 12, 2017
@vicb

vicb commented Jan 12, 2017

Copy link
Copy Markdown
Contributor

/cc @pkozlowski-opensource

@pkozlowski-opensource pkozlowski-opensource added the area: common Issues related to APIs in the @angular/common package label Jan 16, 2017
@pkozlowski-opensource pkozlowski-opensource self-assigned this Jan 16, 2017

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DzmitryShylovich do you have any source reference for this RegExp?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is super-light on tests.... I would expect that a change like this comes with much, more tests for both valid and invalid cases.

As a comment for the existing test: if we expect sth to not throw we should assert what should be the exact result, not just the fact that it doesn't throw.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned above, my biggest grip with this PR is that we don't have enough tests... As the very minimum we should:

  • add tests that demonstrate what happens for invalid inputs (ex.: 2015-06-15Taaaaa
  • what is the output for "valid" cases - as of today this PR just check that we don't throw but I could make those tests pass by deleting all the code from the pipe...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if the input is a string but not a valid ISO string? If I'm reading the code correctly it will still try to create Date object, right? But what is the point if we know that the string is invalid?

@DzmitryShylovich DzmitryShylovich Jan 16, 2017 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will still try to create Date object, right?

yeap. afaik there's no universal pattern for a iso 8601 date. So even if a string doesn't match our regex it can still be a valid date in some browsers. Sort of a fallback. But we can probably remove

} else {
   date = new Date(value);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think that we should decide if we parse date ourselves or still mess with the Date object. If I'm reading things correctly ng1 is taking over parsing completely: https://github.com/angular/angular.js/blob/dea8ae9af0e59b6727f3f732ea1fae8bb4368b0a/src/ng/filter/filters.js#L613-L623

So even if a string doesn't match our regex it can still be a valid date in some browsers.

Do you have examples? Or is it sth that you suspect?

@pkozlowski-opensource

Copy link
Copy Markdown
Member

@DzmitryShylovich I'm on a fence with this one - I'm not super-keen on duplicating parsing logic... let me think about this one some more. In any case it would need much more tests if we go down this path.

@mhevery

mhevery commented Jan 28, 2017

Copy link
Copy Markdown
Contributor

@pkozlowski-opensource can we get this labeled for merge or close?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned above, my biggest grip with this PR is that we don't have enough tests... As the very minimum we should:

  • add tests that demonstrate what happens for invalid inputs (ex.: 2015-06-15Taaaaa
  • what is the output for "valid" cases - as of today this PR just check that we don't throw but I could make those tests pass by deleting all the code from the pipe...

@pkozlowski-opensource pkozlowski-opensource added the action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews label Jan 30, 2017
@pkozlowski-opensource

Copy link
Copy Markdown
Member

@DzmitryShylovich so my biggest issue with this PR is that we don't have enough tests and as such we can't guarantee that we are not introducing breaking changes... Also i18n-related pipes are pending rewrite so I'm not keen on merging anything that is not critical.

If you could more tests to this PR (especially ones exploring corner cases) we could merge it but I fell uneasy getting it in as-is.

@DzmitryShylovich

Copy link
Copy Markdown
Contributor Author

@pkozlowski-opensource ready for review

we can't guarantee that we are not introducing breaking changes

ok I added parsing at the end, where we already know that string is not a valid date in browser, so we won't introduce a breaking change accidentally.

@pkozlowski-opensource pkozlowski-opensource removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews action: review The PR is still awaiting reviews from at least one requested reviewer labels Feb 1, 2017
@pkozlowski-opensource

Copy link
Copy Markdown
Member

This one is good to go if you ask me.

@pkozlowski-opensource pkozlowski-opensource added the action: merge The PR is ready for merge by the caretaker label Feb 1, 2017
@mhevery mhevery closed this in 093cc04 Feb 1, 2017
mhevery pushed a commit that referenced this pull request Feb 3, 2017
mhevery pushed a commit to mhevery/angular that referenced this pull request Feb 3, 2017
mhevery pushed a commit to mhevery/angular that referenced this pull request Feb 3, 2017
asnowwolf pushed a commit to asnowwolf/angular that referenced this pull request Aug 11, 2017
asnowwolf pushed a commit to asnowwolf/angular that referenced this pull request Aug 11, 2017
juleskremer pushed a commit to juleskremer/angular that referenced this pull request Aug 28, 2017
juleskremer pushed a commit to juleskremer/angular that referenced this pull request Aug 28, 2017
@angular-automatic-lock-bot

Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot Bot locked and limited conversation to collaborators Sep 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: merge The PR is ready for merge by the caretaker area: common Issues related to APIs in the @angular/common package area: i18n Issues related to localization and internationalization cla: yes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Safari only] Invalid argument for pipe 'DatePipe' - Safari cannot parse Date offsets

6 participants