[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240293#comment-13240293
]
Thomas Neidhart commented on LANG-796:
--------------------------------------
The whole idea of DateUtils is to provide convenience methods when manipulating
Date objects. The use-case that you describe, and I assume that's quite a
common one, requires a properly configured Calendar object. Now we could add a
method like this:
{noformat}
public static Date add(Date date, int calendarField, int amount, Calendar
cal) {
cal.setTime(date);
cal.add(calendarField, amount);
return cal.getTime();
}
{noformat}
But what's the point of it? If you already have the Calendar that you want to
use, why not just do it straight-away?
The fix that you propose would only support the UTC timezone, and will return
wrong results for different timezones in case of a DST. While you are right,
when you say that a Date object is not influenced by DST, any manipulation of
it is in fact (or better could, depending on the timezone). When you need to
operate in UTC time, always use proper configured Calendars (and also
Formatters) for the UTC timezone (or set your local timezone to UTC).
> DateUtils.addDays does not work properly with daylight saving time (DST)
> ------------------------------------------------------------------------
>
> Key: LANG-796
> URL: https://issues.apache.org/jira/browse/LANG-796
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Affects Versions: 2.6
> Reporter: Nicola Barbiero
>
> DateUtils.addDays does not work properly with daylight saving time.
> The signature of the method is
> Date addDays(Date date, int amount)
> and the javadocs says "Adds a number of days to a date returning a new
> object. The original date object is unchanged",
> so if X=date.getTime() is the number of milliseconds of the date in input,
> the expected behaviour is that the returned Date has a number of milliseconds
> equal to X+amount*(86400000), where 86400000 is the number of milliseconds in
> one day.
> But when the calculation goes across the DST change date, the number of
> milliseconds added does not correspond to whole days.
> For example, here in Brussels, this code fragment:
> Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[]
> { "dd-MM-yyyy_HH:mm" });
> Date output = DateUtils.addDays(input, 1);
> will give:
> 'input' equals to "Sun Mar 25 00:00:00 CET 2012" ==> input.getTime()
> equals to 1332630000000
> 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime()
> equals to 1332712800000
> where 1332712800000-1332630000000=82800000 < 86400000
> (in fact 82800000 is equivalent to 23h).
> Since addDays is working with objects Date, it should not be influenced by
> events like the DST.
> Proposed solution: replace the current implementation
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> c.add(calendarField, amount);
> return c.getTime();
> }
> based on Calendar with an implementation that works only with Date objects,
> for example:
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> return new Date(input.getTime() + amount * 86400000l);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
