Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 24 Sep 2014 14:59:35 +0000 (UTC)
From: "Duncan Jones (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12548305.1332854458000.112716.1411570775010@Atlassian.JIRA>
In-Reply-To: <JIRA.12548305.1332854458000@Atlassian.JIRA>
References: <JIRA.12548305.1332854458000@Atlassian.JIRA>
 <JIRA.12548305.1332854458035@arcas>
Subject: [jira] [Updated] (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:all-tabpanel ]

Duncan Jones updated LANG-796:
------------------------------
    Description: 
{{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:

bq. 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:

{code:java}
Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[] { "dd-MM-yyyy_HH:mm" });
Date output = DateUtils.addDays(input, 1);
{code}

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

{code:java}
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();
    }
{code}

based on Calendar with an implementation that works only with Date objects, for example:

{code:java}
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);
    }
{code}


  was:
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);
    }


> 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
>             Fix For: Patch Needed
>
>
> {{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:
> bq. 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:
> {code:java}
> Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[] { "dd-MM-yyyy_HH:mm" });
> Date output = DateUtils.addDays(input, 1);
> {code}
> 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
> {code:java}
> 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();
>     }
> {code}
> based on Calendar with an implementation that works only with Date objects, for example:
> {code:java}
> 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);
>     }
> {code}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)