this post was submitted on 06 Nov 2023

31 points (69.1% liked)

Programmer Humor

32415 readers

1025 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 5 years ago

MODERATORS

AgreeableLandscape@lemmy.ml

cat_programmer@lemmy.ml

If you run this JavaScript function on the 31st of a month, the result will be a month off. The best part is that this is the intended behvaior. JavaScript is a cursed language. (lemmy.ml)

submitted 1 year ago by yogthos@lemmy.ml to c/programmerhumor@lemmy.ml

47 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] generic@iusearchlinux.fyi 9 points 1 year ago* (last edited 1 year ago) (1 children)

date.setDate(1);

Problem solved.

[–] yogthos@lemmy.ml 0 points 1 year ago (2 children)

Sure, but the question is why anybody thought this would be a desirable behavior in the first place.

[–] ricecake@sh.itjust.works 17 points 1 year ago (1 children)

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.

[+] yogthos@lemmy.ml -7 points 1 year ago (2 children)

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.

[–] ricecake@sh.itjust.works 3 points 1 year ago (1 children)

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 != date in 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.

[+] yogthos@lemmy.ml -7 points 1 year ago (1 children)

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.

[–] ricecake@sh.itjust.works 2 points 1 year ago (1 children)

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.

[+] yogthos@lemmy.ml -7 points 1 year ago (1 children)

Are you seriously arguing that this is the behavior a person using this API would intuitively expect?

[–] ricecake@sh.itjust.works 2 points 1 year ago (1 children)

What behavior do you expect? Specifically.

I'm arguing that every answer is wrong, and will return bizarre results, be aggravating, useless or some combination therein for some conditions.
Therefore you have to know the API, because every language will fuck you, and JavaScript isn't special in this specific case.

Adding the number of days in the month to the date as "add one month" is just as rational as any other choice.

[+] yogthos@lemmy.ml -7 points 1 year ago (1 children)

The behavior I would expect would be to throw an error when the date is outside of the range of valid dates for the month. If you try to create a date on February 31st throw an error. Have you seriously never used a good API that's intuitive and isn't full of gotchas?

[–] ricecake@sh.itjust.works 1 points 1 year ago (1 children)

Have you never done Datetime math before?

You didn't run new Date(2019, 02, 31), you asked it for one month from January 31st.
One month after any given day of the month is, by most people's intuition, a valid thing to ask for.

Your solution of making the API throw an exception for every 31st of the year is vastly less intuitive to me than "a month is 31 days in January, and 28 or 29 in February, so adding a month does different things in different months", because at least for those is can also query how many days are in the month.

If I say to add four days, will it throw an exception if it's the 31st? No month has 35 days, so I should get an exception, right?
Or is it just this weird caveat around months? Does it apply to time?

[–] yogthos@lemmy.ml -5 points 1 year ago* (last edited 1 year ago) (1 children)

One month after any given day of the month is, by most people’s intuition, a valid thing to ask for.

Nobody actually thinks this way, when you ask somebody what's the next month they don't go, oh today is the x day of the month and I'm going to add days to the current date to see what's the next month. That's not how vast majority of people think about this intuitively. Clearly you and people who designed Js Date API do though.

“a month is 31 days in January, and 28 or 29 in February, so adding a month does different things in different months”

That's how months work. Each month has a different number of days.

If I say to add four days, will it throw an exception if it’s the 31st? No month has 35 days, so I should get an exception, right?

Yeah, it's how months work.

In fact, this isn't a hypothetical argument this is how date APIs work in sane languages like Java. For example:

java.time.LocalDate.of(2023, 2, 31)
> java.time.DateTimeException: Invalid date 'FEBRUARY 31'

java.time.LocalDate.of(2023, 2, 3)
> #object[java.time.LocalDate 0x2bc77260 "2023-02-03"]

The fact that you think what Js API dies is preferable to this is frankly surreal to me.

[–] ricecake@sh.itjust.works 1 points 1 year ago (1 children)

So, you're talking about throwing exceptions if adding a month yields an invalid date if done without nuance, but then you're showing an example of just trying to instantiate an invalid date in java.

I believe java has an addMonths method, that in the situation we're talking about doesn't throw an exception, but rather limits the output to the 28th/ 29th/30th.

Which illustrates my point: intuitive Datetime math involves choosing how you handle edge cases that are routine and not exceptional, like "a month from January 31st".

The rest of your comment arguing about how people expect months to work just makes me feel like you've never actually talked to a business stakeholder about requirements.

If I say to add four days, will it throw an exception if it’s the 31st? No month has 35 days, so I should get an exception, right?

Yeah, it's how months work.

That's just insane. An API that doesn't increment the month when you pass the end while adding days is just broken.

[+] railsdev@programming.dev 2 points 1 year ago* (last edited 1 year ago) (2 children)

[deleted]

[–] ricecake@sh.itjust.works 1 points 1 year ago (1 children)

So, the flip side to that is that sometimes you need to add one month to a date, because that sometimes how human systems are written.
By not providing a function that does that, you're just pushing the confusion down to the developer, who is more likely to make terrible errors in the process, get frustrated, or use one of N different competing libraries, each of which chose a different answer.

Omitting functionality that can behave unintuitively in certain circumstances means leaving out a lot of functionality that people need.

Like, "decimal numbers" go pathological in certain cases. So do Unicode characters. Don't even bother thinking about connecting to the network.

[–] yogthos@lemmy.ml -4 points 1 year ago

Exactly, it's better to not have these sorts of "conveniences" than to create weird pitfalls. I find a lot of crazy Js behaviors are ultimately a result of Js trying to be accommodating of inputs that should just be straight up rejected.

[–] erogenouswarzone@lemmy.ml 4 points 1 year ago (2 children)

I love js. But the date object has always been a total pain. Moment.js is a good package to deal with it, but yeah, it's currently deprecated, but it would be nice if it or something like it became part of ECMAScript.

I have no idea why it hasn't yet, except that it might be that js needs to work for everyone, not just the us. So time is not standard.

[–] towerful@programming.dev 3 points 1 year ago* (last edited 1 year ago) (1 children)

The date API is like the original rip of the Java date API. Barely changed, and totally backwards compatible nonsense.

Temporal is the new JavaScript/ECMAScript date API.
It's stage 3, and likely stable (just a few kinks being worked out). So you could polyfill it for production.
https://github.com/tc39/proposal-temporal

[–] erogenouswarzone@lemmy.ml 2 points 1 year ago

Speaking of Java RipS. How annoying is it the JS has left Java in the dust as far as looser standards?

Developing in Java: YOU FORGOT A SEMI-COLON ARE YOU CRAZY?! HOW IS THE COMPILER SUPPOSED TO KNOW WHAT TO DO?!

Developing in JS: Who gives a fuck about semi-colons?

[–] CannotSleep420@lemmygrad.ml 2 points 1 year ago

You may be interested in the datefns library if you need a replacement for momentjs.