commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brady Ellison (JIRA)" <>
Subject [jira] [Commented] (LANG-771) DateUtils.ceiling does not behave correctly for dates on the boundaries
Date Fri, 19 Oct 2012 18:35:11 GMT


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 []
hold for date math.

The function is exactly equivalent to (plus its variants):
Date input = new Date();
Date truncatedToDate = DateUtils.truncate(input, Calendar.DATE);
Date output = DateUtils.addDays(truncatedToDate, 1);

Naive fix: (only for non-negative dates)
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)==
  output = truncatedToDate;
} else {
  output = DateUtils.ceiling(truncatedToDate, field);
> DateUtils.ceiling does not behave correctly for dates on the boundaries
> -----------------------------------------------------------------------
>                 Key: LANG-771
>                 URL:
>             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|])
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:

View raw message