-
Bug
-
Resolution: Fixed
-
P4
-
16
-
b04
-
Verified
A DESCRIPTION OF THE PROBLEM :
The method java.time.Duration.toDaysPart() is extremely misleading:
- All other "...Part()" methods return the remainder of dividing by the next larger unit; so naturally a user might assume the result is the part of the days in a month (30 days?) or a year (365 days?)
- It behaves exactly the same as `toDays()` but the documentation does not make this obvious
This makes `toDaysPart()` misleading and redundant. Personally I would prefer deprecating the method (for removal) to prevent further confusion caused by this method.
However, if you (for some strong reason) want to keep the method, then please change its documentation (i.e. remove the complete existing documentation text) to:
> This method behaves exactly the same way as {@link #toDays()}.
Then at least most of the confusion is removed, and users don't waste their time trying to understand the difference.
The method java.time.Duration.toDaysPart() is extremely misleading:
- All other "...Part()" methods return the remainder of dividing by the next larger unit; so naturally a user might assume the result is the part of the days in a month (30 days?) or a year (365 days?)
- It behaves exactly the same as `toDays()` but the documentation does not make this obvious
This makes `toDaysPart()` misleading and redundant. Personally I would prefer deprecating the method (for removal) to prevent further confusion caused by this method.
However, if you (for some strong reason) want to keep the method, then please change its documentation (i.e. remove the complete existing documentation text) to:
> This method behaves exactly the same way as {@link #toDays()}.
Then at least most of the confusion is removed, and users don't waste their time trying to understand the difference.
- csr for
-
JDK-8269042 Clarify the method description of Duration.toDaysPart()
-
- Closed
-
- relates to
-
JDK-8142936 Add java.time.Duration methods for days, hours, minutes, seconds, etc.
-
- Resolved
-