I am more surprised it is about numbers. I found it more important to take care when dealing with date ranges in databases. And SQL "BETWEEN" lures you into using [from, to], which is great way to shoot yourself in foot. So just my 2 cents:

- what are you going to do when you need to split [a,b] into multiple parts, for performance reasons? [a,c], (c,b] ? Can your codebase handle different interval types? Having [a,b) everywhere is simpler

- stuff like 23:59:59.999999999 is code smell, well until database rounds it up, to next day, then it turns into bug

A system I work on chose to use [closed, closed] intervals for date time intervals, where multiple intervals should be adjacent, but not overlapping. So the intervals look like 2022-11-22T00:00:00.000Z - 2022-11-22T23:59:59.999Z. Of course the codebase is sprinkled with +/- 1ms, and off-by-one issues causing date times to match _no_ interval. [closed, open) would've been so much easier to work with and reason about.

Why not? The precision one sounds convincing and I don't have any obvious counters

Let's say you want to find accommodation from day x to y, would you rather have [x, y + 1) as the interval in the code?

In other words, I think the blog post lists problems the author has had and in those cases an open-closed interval would have worked better. But one could come up with an opposite case, would that be equally true?

Of course if datetimes are involved, you need to go up midnight. So you’re back to +1 and a half-open range

IIRC (bit rusty now) python makes you do exactly [x, y + 1) in code and it pisses me off which is why I did my own trivial end-is-included range for loops.

Otherwise would result in surprises like range(10) giving 11 values, violating convention. I admit I usually have to pause to remember whether it's inclusive of the upper bound or not.