Good Design is Imperfect Design, Part 1: Honest Names • Hacker News Board

Re: Good Design is Imperfect Design, Part 1: Honest Names

#131

Post by goto11 » Thu, Aug 05, 2021, 3:34 PM UTC

TeMPOraL wrote: post #123

hcarvalhoalves wrote: post #90

The problem is not in the `plus` method, as it's working as expected when the unit is in days. It's the `month` unit that is misleading, since `1 month` looks like a constant value but really isn't, as the behaviour depends on the other operand, breaking associativity – or any expectation on how addition between two constants work really. It would be less confusing if the API removed `month` as a period, and as a pro…

The month itself is unnecessary complex because long ago, someone decided to break a perfectly good calendar. Ever wondered why the variable-length month is second in the year, instead of a last? English names of months offer a hint: "September", "October", "November", "December" - sound similar to "hept-", "oct-", "non-", "dec-", i.e. 7th, 8th, 9th and 10th. So as it turns out, February used to come last, as reason…

Doesn't really change that adding n months to a date is an ambiguous operation. You would need to give all months the same length to avoid the ambiguity, but then months would not add up to a year, which has its own set of problems.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#132

Post by stickfigure » Thu, Aug 05, 2021, 4:41 PM UTC

hcarvalhoalves wrote: post #90

The problem is not in the `plus` method, as it's working as expected when the unit is in days. It's the `month` unit that is misleading, since `1 month` looks like a constant value but really isn't, as the behaviour depends on the other operand, breaking associativity – or any expectation on how addition between two constants work really. It would be less confusing if the API removed `month` as a period, and as a pro…

As others have pointed out, `plus` has odd behaviors for days, hours, and minutes too (DST, leap seconds). That's because dates are weird.

Absolutely anyone who works with dates needs to understand this. There's no point in calling the method `plusWeird`, that's redundant.

The good news is that most people actually have an intuitive understanding of dates (because we have spent our lifetimes looking at calendars) and when you are doing exotic date math ("move this to the same date next month") the default behavior of `plus` is what you want.

I spent a lot of time working with Joda Time (and now java.time). I use date math functions on the regular, professionally. I found this API intuitive and ergonomic from the get-go, and well matched to the problem domain. What I see in this thread is a bunch of people with a relatively poor grasp of the problem domain trying to rethink the API.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#133

Post by hcarvalhoalves » Fri, Aug 06, 2021, 3:48 AM UTC

slaymaker1907 wrote: post #49

ithkuil wrote: post #42

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.

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.

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 - Just plus 3 calendar month plus remaining days if > end of month

- 90 days from now