Close on selection of month instead of year when dateFormat is set to display quarter

[MilosRasic]

Description

Altered getUpdateOn() method to return 'months' when Q token is used in dateFormat. In case of dateFormats like YYYY-[Q]Q, it would detect Y token and return 'years' instead, but month selection is required to specify a quarter of a year.

Motivation and Context

My team ran into this problem while using react-datetime with closeOnSelect=true to control data for rendering of charts in which date grain can also be selected in another component. Changing date grain updates dateFormat prop on datepickers. It works fine for all formats except YYYY-[Q]Q where it closes when year is selected, making it impossible for user to get to months view.

Also added a test case to check week of the year format (for example gggg-[W]ww), which is also something we use. This is currently working correctly because all token detection fail and the method returns 'days' by default. I feel however that it would be easy to break with future changes since it relies on the default return, hence a new test case.

Checklist

[x] I have added tests covering my changes
[x] All new and existing tests pass
[ ] My changes required the documentation to be updated
  [ ] I have updated the documentation accordingly
  [ ] I have updated the TypeScript 1.8 type definitions accordingly
  [ ] I have updated the TypeScript 2.0+ type definitions accordingly

[MilosRasic]

Any chance of a maintainer taking a look at this? I know it's not a common use case, but it the PR really makes sense, passes all tests and adds new ones to cover the use cases it addresses. Do you want a new PR against more recent master to avoid merge conflicts?

[layneanderson]

Hi @MilosRasic ,

This looks interesting, unfortunately I don't have the time right now to properly review it. Christmas is peak season for the company I work for, so I don't have a lot of spare time right now, and the spare time I do have I'm spending with family. Hopefully one of us will be able to review early in the new year.

I just wanted to let you know why there is a delay. Thanks for contributing!

[simeg]

Hi @MilosRasic. Again, sorry for the delay. This is quite a big PR (+2,125 −57). No need to include the dist files in your PR, we do that when we publish a new version :)

I'll take a look at this tomorrow when my head is more clear, thank you for your contributions!

[MilosRasic]

@simeg Since we really needed this change, we started using our own fork. Unfortunately, when I transferred the fork to the org I wasn't expecting that github would keep tracking changes and updating the PR, and we've made a few new ones on the fork.

I can make a new PR without the unrelated changes and dist directory if that's ok with you.

The other change we made is adding a "today" button. If that's something you would like in the main repo we could also make another PR for that.

[simeg]

@MilosRasic I see. A separate PR sounds like the best. If possible, split the PRs between the two new features that you introduce. It would make things so much easier for us. Thank you, and again thanks for spending time on contributing! ⭐️

[simeg]

Closing this due to reasons above, awaiting new PR(s).

[MilosRasic]

replaced with #523 and #524