function getMonthName(monthNumber) {
const date = new Date();
date.setMonth(monthNumber - 1);
return date.toLocaleString([], { month: 'long' });
}
Somebody has not worked with dates for very long, to be so sure of themselves…
I’ve worked with dates long enough in lots of different languages to recognize API decisions that are absurd.
date.setDate(1);Problem solved.
Sure, but the question is why anybody thought this would be a desirable behavior in the first place.
It’s because there’s no right answer, and this way gets you the intuitive answer most often.
A month isn’t a proper unit of time. Adding a month to a date can’t be done without specifying which month you’re adding.
You could argue that one month from January 31 is February 28, 29 (depending on the year), March 2, or 3.
Should one month from the last day be the last day of the next month? That would mean that the 30th and the 31st of march are both the same duration from April 30th, and a month before April 30th could logically map to either one.
So they chose the path that, for anything other than the 31st, and the 29th and 30th if it comes near February, works as you expect. "A month after 17 days from the first of January is 17 days after the first of february.”
The other alternatives involve not allowing the addition and subtraction of irregular time intervals, but then you get frustrated that you can only deal with seconds, since those don’t change in length.
Having restrictions is far better than having random pitfalls that you fall into. An API works as you’d expect majority of the time and then has an edge case that’s entirely not obvious is a bad API. The whole problem with Js is that it’s full of rakes that you can step on. You can rationalize every one of these weird behaviors in Js, but that doesn’t make the language any easier to work with in practice. People forget a random rule here or there and then their code breaks in weird ways when the stars align just right. This is simply not how APIs should be designed.
In this case though, it’s consistent, and is just one of the annoying ways the problem could be solved. Datetime math is just fucked up.
You can just not support that functionality, which gives you people making their own mistakes and forgetting leap years or hard coding all sorts of insanity.
You can clamp the value to the end of the month, but that gives you the odd case where
date + month - month != datein some days, which is also a weird pitfall.If I see any code dealing with adding and subtracting months, I’m either checking the manual or I already know it’s behavior from doing so before.
I’m all about not liking how JS does stuff, but Datetime math is the one area where in willing to forgive most insanity of outcomes.One way to solve the problem is to give an error when you end up with an invalid input such as a data outside the range of valid dates for the month. The other way to solve the problem is to silently return nonsense which is what Js does. It’s just a matter of doing basic input validation.
Except it’s not nonsense. If you ask for 31 days after January 31st, you don’t get February 28th.
A month is a malformed concept to use in conjunction with arithmetic, except for the part where people do it all the time and just ignore the fact that it often gets weird.
Do you really think you’d be happier if the answer for "what’s a month from 01/31?” was “InvalidDateException”? That every other month the concept of “a month from today” is just undefined?
Saying “adding a month means adding the number of days in the starting month” is one choice of many, all of which have terrible downsides.
Are you seriously arguing that this is the behavior a person using this API would intuitively expect?
You want to create the date “31st February”, but it’s JavaScript that’s cursed?
Write a less side-effecty function.
function getMonthName(monthNumber) { const date = new Date(2023, monthNumber - 1, 1); return date.toLocaleString([], { month: 'long' }); }The point is that this scenario exists in Js in the first place. It’s a completely unnecessary rake left around for people to step on. Also, the function isn’t side effecty since it doesn’t make implicit references outside its scope. The fact that the date is mutable is an internal concern there. You could just as easily do
function getMonthName(monthNumber) { const date = new Date(); date.setDate(1); date.setMonth(monthNumber - 1); return date.toLocaleString([], { month: 'long' }); }The problem here isn’t with side effects, but with having to know that you want to set your date to first day to get the next month reliably.
