[
https://issues.apache.org/jira/browse/LANG-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-771:
------------------------------
Description:
{{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()}}:
{code:java}
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));
{code}
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:
{code}
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>
{code}
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}}).
was:
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).
> 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
> Fix For: Patch Needed
>
>
> {{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()}}:
> {code:java}
> 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));
> {code}
> 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:
> {code}
> 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>
> {code}
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
