Hacker News Reader

Comment by ithkuil | Hacker News Reader

The problem is not the "plus" operator but instead lies in the "month" duration.

Not all months last the same number of days, and while we are at it not all days have 24 hours!

I'd rather move the explicit (and complicated) choice of what kind of month are you talking about (and thus also the relevant discussion about naming) into the operator that constructs a time interval.

View on HN

This is definitely the sort of idea that I like when exploring and trying to find a better model. The point I was trying to make in the article is that there are times when, however you try, you don't find a satisfying answer in the time you have.

Your point was good. But perhaps your unfortunate example is in turn a good example that if you can't find a good name for something perhaps there is a different way to look at things that produces a less contrived (but still explicit and honest) naming scheme.

Looking forward to read about your explorations on that front.

That's not really always possible/practical. It's pretty common to say "in three months from now" in which case defining a month to be 31, 30, 29, or 28 days is not correct. The plain English meaning is to be on the same day of the month, but add 3 to the month value, probably rounding down if necessary. Therefore, 3 months from January 31st 2021 would be April 30th despite going through February which has 28 days.

I think the point of the person you're replying to is to move the ambiguity onto the month object and off the plus operator. So today.plus(1 monthish) rather than today.plusish(1 month).

but this breaks down when the destination date is not within the calendar days of the month. For example, what is 3 months from Nov 30th? Should it be Feb 28th (or, if it's a leap year, should it have been 29th?), or should it be Mar 2nd?

It may be common and still completely ambiguous what “3 months from now” means — ask people around and you’ll get different answers.

- Same calendar day plus 3 calendar month, round down if < end of month

- Just plus 3 calendar month plus remaining days if > end of month

- 90 days from now

I came across this problem once before and came to the same conclusion. “A month” is an ill-defined unit, so I just don’t allow it to be representable in datetime arithmetic. You make the point that “1 day” would also fall under this category, but it’s less variable and so it being equal to “24 hours” is good enough.

One can argue that when something works most of the times until it breaks in some edge cases (twice a year) it's actually more dangerous since you're unlikely to encounter those issues until it hits all of your customers at once.

Reply on news.ycombinator.com