JavaDurationGetSecondsToToSeconds rule is misleading and possibly harmful

[climategadgets]

Expected Behavior

toSeconds() accounts for seconds and nanos, unlike getSeconds(). This is confirmed by AI Overview (screenshot below).

Actual Behavior

toSeconds() is implemented by return seconds; all the way to JDK 25. Hence, getSeconds() and toSeconds() return identical result. The way the rule is phrased may lead the user to believe these results are different and cause errors when a "conversion" is attempted.

Screenshot

Interestingly, this AI Overview seems to be using the JavaDurationGetSecondsToToSeconds rule text to generate the advice, thus possibly creating a circular hallucination.

[cushon]

I agree that toSeconds and getSeconds have the same behaviour. The check is enforcing a policy that tries to make code using these methods more consistent and easier to read. Note that the getNano and toNano methods are different in a way that can be bug prone: https://errorprone.info/bugpattern/JavaDurationGetSecondsGetNano

The recommendation is to always use getSeconds and getNanos together if you're composing a duration into second and nanos parts, and the to methods if you're converting the entire duration to a specific unit.

[climategadgets]

The intent is clear, but things become anything but consistent in reality because Duration itself isn't. The only four methods that account for nanoseconds are toMillis(), toNanos(), toMillisPart(), and toNanosPart(), the rest of them ignore nanoseconds altogether.

Since Duration, as implemented, is there to stay or the world will start breaking, a nice closure for this issue would be to adjust the wording so that it doesn't imply getSeconds() and toSeconds() return a different result.

[graememorgan]

Could you suggest an alternative wording? I'm struggling to come up with anything, because I don't think the current wording implies that they return different results.