[derjdoj]

Please don’t have a method named plusIshRoundCeiling() in a library that “might” be used for years in lots of projects :) The plus() one is almost there and you can easily explain the ugly bits in javadocs (with lots of warnings around it so that it sticks out and is addressed hopefully in some next convenient cycle)

[ericevans]

I was trying to be funny here! There is lots of room between "plus", which I think is misleading, and the kitchen sink name you quote. Although it depends on how serious the problems were, in this case I'd pick something shorter that still suggested rough edges.

[derjdoj]

Makes perfect sense, I thought so as well. It just made me think hope somebody doesn't assume this would be the best name in this case :)

[bspammer]

plusIshRoundCeiling() forces the reader to look at the javadocs to understand the edge cases, and in fact it serves as a reminder that there even are any edge cases.

[majormajor]

> (with lots of warnings around it so that it sticks out and is addressed hopefully in some next convenient cycle)

How do you expect to address it when there isn't a single obvious "right" that everyone will have the same intuition on?

[derjdoj]

For instance, as in the article, provide the examples so that the users have more heads-up as in what is actually happening.

Long term, you might deprecate it and solve the problem with more intuitive abstraction.

[progman32]

Can you explain why you see this name as unacceptable?

[derjdoj]

I did’n quite intended to sound as if I think it would be unacceptable but the method name sounded too comical to me to be honest. Almost as if the intention is to say this method is a bit of a joke don’t use it please.

Maybe move() might work better here or moveToCalendarNearest() or something to flag up that in certain cases you need to be extra careful as mentioned in the article.

It is really hard to get this right and personally I would be flagging it up in javadocs.