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

Suggested feature: allow range to explicitly direct itself #106

Open
jrencz opened this issue Feb 18, 2016 · 4 comments
Open

Suggested feature: allow range to explicitly direct itself #106

jrencz opened this issue Feb 18, 2016 · 4 comments

Comments

@jrencz
Copy link

jrencz commented Feb 18, 2016

Now if interval is passed then it's implicitly directed: https://github.com/gf3/moment-range/blob/72e31df65da59e39dbde540c500d8d7da4f82995/lib/moment-range.js#L321-L323
but if 2 moment objects are passed they are not. And there's no way to direct the range created that way.

It would be nice to be able to pass any 2 dates to range() and call some method that will direct the dates so earlier date is start and later date is end no matter which order they were passed in to the range() function.

It may work like this:

moment.range([
  momentA,
  momentB
].sort((a, b) => Math.sign(a.diff(b))))

Suggested api:

moment.range(momentA, momentB).direct()

optionally direct() method might could take a parameter and if it's falsy or negative the range should be directed from later moment do earlier (Math.sign(b.diff(a)))

@gf3
Copy link
Contributor

gf3 commented Dec 8, 2016

the constructor could implicitly do this? thoughts?

@gf3 gf3 added the enhancement label Dec 8, 2016
@jrencz
Copy link
Author

jrencz commented Dec 13, 2016

this way it will not be backwards compatible (although logical). IMO Either a method or on next major release

@lukemcgregor
Copy link

What about

moment.range(momentA, momentB, true);

That way in the next major version you can throw it away by ignoring the extra argument or exceptioning on === false.

@TristanJM
Copy link
Contributor

We're looking at compiling all the breaking changes into the next major release (4.0.0) and I expect this feature will make a good candidate.

We thought the simplest approach was to make the constructor always perform this behaviour. I can't think of any reasons why you would ever want a reverse-time range? Even if a case does exist, it makes sense to keep the library working for forward ranges as the user can easily add their own application logic to keep track of it.

Our proposed solution: #201

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants