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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
That's how months work. Each month has a different number of days.
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:
The fact that you think what Js API dies is preferable to this is frankly surreal to me.
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.
That's just insane. An API that doesn't increment the month when you pass the end while adding days is just broken.
I encourage you to actually try using Java API to see how it works if you don't think my example is illustrative enough. Meanwhile, the only insane thing here is you thinking that how an API works has anything to do with business stakeholders and requirements. This statement clearly illustrates that you don't understand how to translate business requirements into code and perhaps should spend some time learning how to do that instead of trolling here.