d.getMonthsBetween(date);

Question

d.getMonthsBetween(date);

Closed this issue 10 years ago · 28 comments

bebraw commented 11 years ago

It would be handy to have a getMonthsBetween.

JerrySievert commented 10 years ago

pushed.

Answer 1 · 2013-12-21T08:47:19.000Z

There's a possible implementation over at Stack Overflow.

I've settled for something like this myself:

function getMonthsBetween(from, to) {
    var toYear = to.getYear();
    var fromYear = from.getYear();
    var toMonth = to.getMonth();
    var fromMonth = from.getMonth();

    return (toYear - fromYear) * 12 + (toMonth - fromMonth);
}

There is no one clear way to define the difference apparently so I guess you would just have to pick one convention and document it.

Answer 2 · 2014-06-04T13:56:03.000Z

+1 for this action.

Answer 3 · 2014-06-04T19:05:15.000Z

@JerrySievert Would you accept a PR for this? Does the function I proposed look reasonable to you?

Answer 4 · 2014-06-04T22:06:26.000Z

i would accept a pull request, but i also wonder if:

var d1 = new Date();
var d2 = new Date().add({ months: 2});
d1.getMonthsBetween(d2);

might also be good - essentially calling Date.getMonthsBetween(this, that);

Answer 5 · 2014-06-05T07:26:25.000Z

@JerrySievert Let's go with that.

How do you generate the minified version? I don't see a build script around.

Answer 6 · 2014-06-06T17:48:54.000Z

i build it by hand. the library much predates grunt and companions - at some point i will add grunt and a true minifier.

Answer 7 · 2014-06-06T18:42:04.000Z

@JerrySievert Ok. What if I set up a gulp build for you in a separate PR?

Answer 8 · 2014-06-06T20:55:39.000Z

i normally stick with grunt, but would happily accept a gulp pull request.

Answer 9 · 2014-06-09T12:07:11.000Z

@JerrySievert I made PR for gulp build. Once that's merged, I'll implement this one.

Answer 10 · 2014-06-16T08:22:18.000Z

Hey, I realized there's actually getMonthsBetween as a polyfill already. Demo:

require('date-utils);

var a = new Date(2013, 2, 30);
var b = new Date(2013, 4, 30);

console.log(a.getMonthsBetween(b)); // 2.00215

That's in test spec too.

Please mention this at README amongst instance methods and close the issue. Thanks!

Answer 11 · 2014-06-16T16:37:40.000Z

ultimately, the README is not the best place for any of this. the code should really be documented all the way through, and exported as a github site.

i can start that up.

Answer 12 · 2014-06-16T18:07:51.000Z

ultimately, the README is not the best place for any of this. the code should really be documented all the way through, and exported as a github site.

Ok, cool!

Keep in mind having a clear README is important as it's the entry point for users that come through NPM.

Answer 13 · 2014-06-16T19:26:22.000Z

agreed, but the project is big enough now that it needs a lot better documentation than it currently has.

Answer 14 · 2014-06-16T19:27:13.000Z

agreed, but the project is big enough now that it needs a lot better documentation than it currently has.

Sure! Let me know if you need something in terms of tooling etc.

Answer 15 · 2014-06-20T14:46:01.000Z

sorry for taking so long to get back - been slammed with my "day job" for the last couple of weeks.

i'd prefer jsdoc (javascript version), and see that there is a gulp plugin for it - do you want to start, and i can jump in with more docs as my weekend opens up?

Answer 16 · 2014-06-20T19:04:58.000Z

sorry for taking so long to get back - been slammed with my "day job" for the last couple of weeks.

No probs. That's completely understandable. Given it's Summer time things can take longer than usual. :)

i'd prefer jsdoc (javascript version), and see that there is a gulp plugin for it - do you want to start, and i can jump in with more docs as my weekend opens up?

What are your thoughts on v2 (#37)? To make it easier to document we could look into reducing API surface area. Personally I dislike Doxygen style docs that state the obvious. If we can get a tight design on the API, it's easier to document, and more importantly, to use.

Answer 17 · 2014-06-22T05:37:10.000Z

been updating documentation - seem to have run into a bug in either gulp-jsdoc or its documentation.

either way, at least getting a bit of the functionality documented.

Answer 18 · 2014-06-22T05:47:52.000Z

been updating documentation - seem to have run into a bug in either gulp-jsdoc or its documentation.

Can you push the branch up so I can have a look?

Answer 19 · 2014-06-22T05:58:37.000Z

also added complexity - should be very helpful during a refactor for v2

Answer 20 · 2014-06-22T06:06:19.000Z

@JerrySievert Not seeing it yet. Maybe you need to do something along git push origin docs.

Answer 21 · 2014-06-22T06:11:30.000Z

@bebraw https://github.com/JerrySievert/node-date-utils/blob/master/gulpfile.js#L20-L23

pushed to master, since it's 0 code change to the library itself.

Answer 22 · 2014-06-22T06:12:40.000Z

@JerrySievert Ok. Got it. :)

Answer 23 · 2014-06-22T06:39:30.000Z

@JerrySievert Does a standalone jsdoc build work for you? If we can't get the plugin to work, maybe we could skip it and patch something together using something like gulp-shell.

Answer 24 · 2014-06-22T06:41:42.000Z

standalone jsdoc works like a charm - looks like other people are having the same issue with gulp-jsdoc, so it might be an issue with the package itself.

Answer 25 · 2014-06-23T15:57:53.000Z

looks like gulp-jsdoc is not going to work. it now has a disclaimer that it doesn't work and is now unmaintained for the time being. standalone should be fine.

Answer 26 · 2014-06-23T17:14:39.000Z

@JerrySievert Ok. Standalone it is then. :)

Answer 27 · 2014-07-13T16:32:34.000Z

i added a ton of documentation and set up gulp-shell for doc creation. i also added a gh-pages branch.

i will make another doc pass and finish up sometime after world cup (that may not be today).

i also marked a ton of things deprecated, to help get ready for a version 2.

all of that said, going to close this ticket, it's been a fun one!