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.
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
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 != 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.
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.
I agree here. The convenience it may offer to developers who try it might be nice but the trade off is random craziness. I support not supporting features that are unintuitive. In this case that means not allowing someone to add “one month” to a date.
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.
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.
In Ruby (with ActiveSupport) I would do something like 4.days.from_now or 30.days.from_now.
If I really needed “one month from now” on some specific day of the month that not every month has I’d do:
def 31st_of_next_month
next_month = (Time.current.end_of_month + 1.day).beginning_of_month
day = next_month + 31.days
return day if day.month == next_month
# last day of month if no 31st
next_month.end_of_month.beginning_of_day
end
Disclaimer: I’m laying in bed typing this on mobile. The code probably sucks but I’m writing for illustrative purposes.
It seems really weird that there’s so much pushback against “date time math is tricky, read the manual to find out exactly which compromise your library chose”.
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.
The rake has nothing to do with JS (which I agree is cursed, but for its own reasons, not this).
You have called a function in a way that does not give a consistent value (Date()). Such functions are hardly the preserve of JavaScript. You’ve failed to adequately deal with the range of values produced, with code that tries to insist that the “31st February” can be a meaningful date in February. You should accept that this is your mistake and learn to (better) avoid side effects where possible.
Also, the function isn’t side effecty since it doesn’t make implicit references outside its scope.
Edit responding to your edit:
Also, the function isn’t side effecty since it doesn’t make implicit references outside its scope.
The Date() function’s output varies according to something other than its input (and even the rest of your program). Using its output without accounting for that variation means that your function, as originally written, also gives inconsistent return values, varying according to something other than its input, because it does, in fact, reference something outside the function. If it did not, the results would only depend on the monthNumber argument, and would always be consistent. I don’t know what you call that, but I view it as a side effect.
As you have said, the rake is that months have different lengths, and you need to account for that. But that’s not one of JavaScript’s many issues.
The idea is to get the current data that will have the current year, month, day in it, and then to query this date for the previous month. A sane API would just throw an error when the date is out of range. A Js API will quitely give you nonsense instead. Again, side effects have absolutely nothing to do with anything here.
You’ve replied while I was editing, so see that regarding what I mean by side effects.
As far as throwing an error when you try to create “31st February”, this wouldn’t actually help much, since the error would still only occur on some days of the year, because your original code doesn’t account for the range of outputs from Date() when called without arguments.
To perform correctly, your code needs to normalise the day of the month, or just create the date more explicitly to begin with, but this is a calendrical issue, not a JavaScript one.
Side effects are when your function has a reference to some state outside its scope and modifies that state. A function that produces different outputs when it’s called, such as getting a current time is not an example of a side effect. Again, the issue here is that Js tries to infer what to do with a bad input, a number outside acceptable range, instead of simply rejecting it.
My point isn’t that you can’t write a better function that’s less error prone, but the fact that Js allows such things to happen in the first place. It’s a very easily avoidable problem at the API level.
I was taught that side effects are not so one-sided, and that changing output in response to outside state (such as the date) is also a side effect, a side effect on the function, rather than a side effect of the function, but I’m happy to use other definitions so long as they’re commonly understood.
As I said before, though, even if JavaScript did throw an error as you’d prefer, it would still allow your function to have date-based problems. They’d be a bit noisier perhaps but no less present, and just as “well it’s worked fine so far”. And that’s because, as I keep saying, the real problem here is using a function with inconsistent output and not thoroughly dealing with the possibilities. An API change wouldn’t alter that. Most of the time it would still let you write bad code.
I also probably agree with you that errors are generally better than silence in response to bad input but, as someone else has said (more or less) it’s not always unreasonable to consider “31st [Month]” as 31 days after the end of [Previous Month]. Without throwing errors, this flexibility is possible. Perhaps the creators believed having to mutate the day-of-month first was an acceptable trade-off for that.
Right, my only point here is that it’s better to throw an error when encountering bad or ambiguous input than trying to infer what should happen. I think tha a lot of problems in Js come from it being too accommodating regarding input, and the just trying to figure out what you might’ve meant. In vast majority of cases, an input of this kind if an indication of an error in the program logic and it’s better to fail on such inputs than to accept them. If somebody passes a date that doesn’t make sense for a current month, it’s almost certainly because they have some logic error in their code. Accepting this date as a parameter simply results in creating a subtle bug in a program that the user likely won’t be aware of and that’s going to be difficult to find in testing.
The legacy Date object has many problems and this is one of them. Another infamous one is that it uses zero-based month numbers: January is the zeroth month and December the 11th month.
This will be fixed Any Day Now™️ when Temporal is released. This is a carefully designed library that supersedes Date and is currently waiting on some standards to be finalized.
What would you expect “-1 month” to do for a date like 31st of March?
Would the result be the same as for “-1 month” on 29th of March?
If you go back 2 months so the 31st is existing again - should that mean that the result of using -1 month twice should be different to using -2 months?
I think it’s just a stupid way to implement something like this as “month” isn’t a defined size so defining it with a fixed value and documenting it properly is a decent solution but noone should use that kind of function in the first place
It is a stupid way to implement it, but the called function is named setMonth()! The minus one is performed externally, so if you set February you expect February, validation should adjust the other fields…
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
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.
date.setDate(1);Problem solved.
Sure, but the question is why anybody thought this would be a desirable behavior in the first place.
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.
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
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?
You may be interested in the datefns library if you need a replacement for momentjs.
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?
I agree here. The convenience it may offer to developers who try it might be nice but the trade off is random craziness. I support not supporting features that are unintuitive. In this case that means not allowing someone to add “one month” to a date.
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.
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.
In Ruby (with ActiveSupport) I would do something like
4.days.from_nowor30.days.from_now.If I really needed “one month from now” on some specific day of the month that not every month has I’d do:
Disclaimer: I’m laying in bed typing this on mobile. The code probably sucks but I’m writing for illustrative purposes.
Why wouldn’t you just use the ruby functions for adding a month to a date?
https://ruby-doc.org/stdlib-2.5.1/libdoc/date/rdoc/Date.html#method-i-3C-3C
It seems really weird that there’s so much pushback against “date time math is tricky, read the manual to find out exactly which compromise your library chose”.
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.
You want to create the date “31st February”, but it’s JavaScript that’s cursed?
Write a less side-effecty function.
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
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.
The rake has nothing to do with JS (which I agree is cursed, but for its own reasons, not this).
You have called a function in a way that does not give a consistent value (
Date()). Such functions are hardly the preserve of JavaScript. You’ve failed to adequately deal with the range of values produced, with code that tries to insist that the “31st February” can be a meaningful date in February. You should accept that this is your mistake and learn to (better) avoid side effects where possible.Edit responding to your edit:
The
Date()function’s output varies according to something other than its input (and even the rest of your program). Using its output without accounting for that variation means that your function, as originally written, also gives inconsistent return values, varying according to something other than its input, because it does, in fact, reference something outside the function. If it did not, the results would only depend on themonthNumberargument, and would always be consistent. I don’t know what you call that, but I view it as a side effect.As you have said, the rake is that months have different lengths, and you need to account for that. But that’s not one of JavaScript’s many issues.
The idea is to get the current data that will have the current year, month, day in it, and then to query this date for the previous month. A sane API would just throw an error when the date is out of range. A Js API will quitely give you nonsense instead. Again, side effects have absolutely nothing to do with anything here.
You’ve replied while I was editing, so see that regarding what I mean by side effects.
As far as throwing an error when you try to create “31st February”, this wouldn’t actually help much, since the error would still only occur on some days of the year, because your original code doesn’t account for the range of outputs from
Date()when called without arguments.To perform correctly, your code needs to normalise the day of the month, or just create the date more explicitly to begin with, but this is a calendrical issue, not a JavaScript one.
Side effects are when your function has a reference to some state outside its scope and modifies that state. A function that produces different outputs when it’s called, such as getting a current time is not an example of a side effect. Again, the issue here is that Js tries to infer what to do with a bad input, a number outside acceptable range, instead of simply rejecting it.
My point isn’t that you can’t write a better function that’s less error prone, but the fact that Js allows such things to happen in the first place. It’s a very easily avoidable problem at the API level.
I was taught that side effects are not so one-sided, and that changing output in response to outside state (such as the date) is also a side effect, a side effect on the function, rather than a side effect of the function, but I’m happy to use other definitions so long as they’re commonly understood.
As I said before, though, even if JavaScript did throw an error as you’d prefer, it would still allow your function to have date-based problems. They’d be a bit noisier perhaps but no less present, and just as “well it’s worked fine so far”. And that’s because, as I keep saying, the real problem here is using a function with inconsistent output and not thoroughly dealing with the possibilities. An API change wouldn’t alter that. Most of the time it would still let you write bad code.
I also probably agree with you that errors are generally better than silence in response to bad input but, as someone else has said (more or less) it’s not always unreasonable to consider “31st [Month]” as 31 days after the end of [Previous Month]. Without throwing errors, this flexibility is possible. Perhaps the creators believed having to mutate the day-of-month first was an acceptable trade-off for that.
Right, my only point here is that it’s better to throw an error when encountering bad or ambiguous input than trying to infer what should happen. I think tha a lot of problems in Js come from it being too accommodating regarding input, and the just trying to figure out what you might’ve meant. In vast majority of cases, an input of this kind if an indication of an error in the program logic and it’s better to fail on such inputs than to accept them. If somebody passes a date that doesn’t make sense for a current month, it’s almost certainly because they have some logic error in their code. Accepting this date as a parameter simply results in creating a subtle bug in a program that the user likely won’t be aware of and that’s going to be difficult to find in testing.
The legacy
Dateobject has many problems and this is one of them. Another infamous one is that it uses zero-based month numbers: January is the zeroth month and December the 11th month.This will be fixed Any Day Now™️ when Temporal is released. This is a carefully designed library that supersedes
Dateand is currently waiting on some standards to be finalized.The amount of people arguing that this is a fine behavior in this thread makes the whole thing even funnier.
I would expect the month to increment by one and the day to be clamped to the valid days for the month.
That’s precisely what I’d expect as well, and what APIs in languages like Java do.
What would you expect “-1 month” to do for a date like 31st of March? Would the result be the same as for “-1 month” on 29th of March?
If you go back 2 months so the 31st is existing again - should that mean that the result of using -1 month twice should be different to using -2 months?
I think it’s just a stupid way to implement something like this as “month” isn’t a defined size so defining it with a fixed value and documenting it properly is a decent solution but noone should use that kind of function in the first place
It is a stupid way to implement it, but the called function is named setMonth()! The minus one is performed externally, so if you set February you expect February, validation should adjust the other fields…
This is literally how every sane API works in languages built by adults. For example, here’s what happens in Java:
I have no idea where people get this notion that a month isn’t a defined size. Do people just not understand the concept of a month?
Oh, because if the month you chose has less than 31 days, it’ll assume the 31st of September is the 1st of October? That’s reasonable.