Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 24 Sep 2012 09:29:07 +1100 (NCT)
From: "Nicola Barbiero (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <1527131946.114377.1348439347557.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <939223651.23118.1332854547637.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (LANG-796) DateUtils.addDays does not work
 properly with daylight saving time (DST)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461528#comment-13461528 ] 

Nicola Barbiero commented on LANG-796:
--------------------------------------

Right, changing the code now might be dangerous...
And of course I agree that an update of Javadoc will be harmless for those who are already using the library, and helpful for everyone.
                
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira