[
https://issues.apache.org/jira/browse/LANG-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480225#comment-13480225
]
Brady Ellison commented on LANG-771:
------------------------------------
Given this behavior the naming of this function is highly misleading. This
ceiling function is not ceiling at all, but a truncate date plus one to the
date's calendar field.
It is probably worth ensuring each item in
[http://en.wikipedia.org/wiki/Floor_and_ceiling_functions#Relations_among_the_functions]
hold for date math.
The function is exactly equivalent to (plus its variants):
{code}
Date input = new Date();
Date truncatedToDate = DateUtils.truncate(input, Calendar.DATE);
Date output = DateUtils.addDays(truncatedToDate, 1);
{code}
Naive fix: (only for non-negative dates)
{code}
int field = Calendar.DATE;
Date input = new Date();
Date truncatedToDate = DateUtils.truncate(input, field);
Date output;
if (input.equals(truncatedToDate)) { // Because if floor(val) == val, then
ceil(val) (should)== val.
output = truncatedToDate;
} else {
output = DateUtils.ceiling(truncatedToDate, field);
}
{code}
> DateUtils.ceiling does not behave correctly for dates on the boundaries
> -----------------------------------------------------------------------
>
> Key: LANG-771
> URL: https://issues.apache.org/jira/browse/LANG-771
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Affects Versions: 3.0.1
> Environment: Windows XP Professional
> Java 1.6
> Reporter: Ryan Holmes
> Priority: Minor
>
> DateUtils.ceiling does not behave as expected for dates exactly on the
> boundaries specified.
> To be consistent with the name "ceiling", it follows that if a date is
> already at its "ceiling", it should not be pushed any higher. Yet the
> current implementation (and, it would appear, all implementations since its
> creation) of DateUtils.ceiling push a value exactly on its ceiling to the
> next value.
> Observe what happens if the following tests are added to
> DateUtilsTest.testCeil():
> double double4 = 15.0;
> assertEquals("ceiling double-4 failed",
> double4,
> Math.ceil(double4));
>
> Date date4 = dateTimeParser.parse("March 30, 2003 01:10:00.000");
> assertEquals("ceiling minute-4 failed",
> date4,
> DateUtils.ceiling(date4, Calendar.MINUTE));
> The first assert passes, as Math.ceil behaves as it should (i.e.
> Mail.ceil(15.0) = 15.0).
> However, the second assert fails with:
> ceiling minute-4 failed expected:<Sun Mar 30 01:10:00 GMT+08:00 2003> but
> was:<Sun Mar 30 01:11:00 GMT+08:00 2003>
> as the routine incorrectly (I believe) pushes the value to the next minute.
> Either the method is incorrectly named ([as previously
> suggested|https://issues.apache.org/jira/browse/LANG-434?focusedCommentId=12855836#comment-12855836])
> or it should probably be corrected to be consistent with expected behaviour
> (using Math.ceil as a benchmark).
> If changing the behaviour of DateUtils.ceiling is perceived to have too many
> flow-on effects (e.g. backwards compatibility issues) then perhaps it should
> be renamed to DateUtils.ceil to make it consistent with the Math class method
> name and to make the change in behaviour obvious (and perhaps also have a
> DateUtils.floor as a synonym for DateUtils.truncate).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
