function getMonthName(monthNumber) {
  const date = new Date();
  date.setMonth(monthNumber - 1);

  return date.toLocaleString([], { month: 'long' });
}

The current day of month will have an impact on the behavior of this method. Conceptually it will add the number of days given by the current day of the month to the 1st day of the new month specified as the parameter, to return the new date. For example, if the current value is 31st January 2016, calling setMonth with a value of 1 will return 2nd March 2016. This is because in 2016 February had 29 days.

  • aebletrae [she/her]@hexbear.netEnglish
    4·
    1 year ago

    the intent of the code is to get the previous month RELATIVE to the current date.

    But that isn’t what it does. From the original post:

    function getMonthName(monthNumber) {
  const date = new Date();
  date.setMonth(monthNumber - 1);

  return date.toLocaleString([], { month: 'long' });
}

    That is a function which is meant to take a number (presumably 1 to 12) and return a localized name for it. This is essentially an array lookup and should return the same output for a given input (and locale) every time it is called. If the intent is to return a value relative to the current date, it is even more wrong, since it should gather the month from the current date, not the function paramenter. This claim of intent, not present in the original post, is an example of you changing your story over time.

    Yes, it would help find the problem faster because the first time invalid date is passed in the program will crash.

    No, it wouldn’t. As I have said before, testing for unexpected return values is just as effective as testing for errors, that is, not very with the function originally presented under sensible assumptions. If the function actually did look like the intent you claim, the tests would be different, necessarily replacing Date for consistent runs, but would be equally likely to catch the problem whether failing on value or error. And if you are eschewing testing and relying on runtime crashes, you have bigger problems.

    Given that I have agreed and commiserated, and neither of us can change JavaScript, there is nothing to be gained from pursuing this complaint. In contrast, what I have tried to say, if followed, would give you an approach that leads to more reliable code, even in the face of undesirable APIs.

    I had thought that worth pursuing, and had thought you worth investing my considerable time. Alas, I can only lead you to the water…

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      28·
      1 year ago

      But that isn’t what it does. From the original post:

      The problem would be the same if you were just doing an offset from the current month. You’re now nitpicking the example while ignoring the point being made. Perhaps this version will help clarify the problem for you better:

      function getLastMonthName() {
  const date = new Date();
  date.setMonth(date.getMonth() - 1);
  return date.toLocaleString([], { month: 'long' });
}

      No, it wouldn’t. As I have said before, testing for unexpected return values is just as effective as testing for errors, that is, not very with the function originally presented under sensible assumptions.

      I’ll repeat this again, the failure case is not obvious and you can easily miss the test for it. Throwing an error makes it much easier to identify that there is a problem, and that’s why APIs in sane languages such as Java behave this way.

      This claim of intent, not present in the original post, is an example of you changing your story over time.

      Nobody is changing the story over time, you’re just incapable of acknowledging being wrong.

      Given that I have agreed and commiserated, and neither of us can change JavaScript, there is nothing to be gained from pursuing this complaint.

      Which is precisely why I posted this on Programmer Humor. Js is a garbage language, and it’s obviously beyond fixing, but I can laugh at it.