[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179981#comment-14179981
]
Josh Chaitin-Pollak commented on LANG-796:
--
I am affected by this situation as well, and I agree with [~nicola.barbiero] -
As he quoted the Oracle specification at the top of bug: Nearly all modern
operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all
cases.
Adding a day should add a 86400 seconds, in all cases, regardless of timezone.
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: 3.3.2
Reporter: Nicola Barbiero
Fix For: Discussion
{{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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150489#comment-14150489
]
Adrian Crum commented on LANG-796:
--
I repeat:
The current behavior is correct. The result added one day. One day is NOT equal
to 8640 milliseconds - as you can see from the result.
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: 3.3.2
Reporter: Nicola Barbiero
Fix For: Discussion
{{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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13796579#comment-13796579
]
Henri Yandell commented on LANG-796:
Javadoc patch needed.
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 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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461108#comment-13461108
]
Duncan Jones commented on LANG-796:
---
I agree with Nicola. A class that intends to work with Date values should not
be interested in daylight savings. I suspect this was an unintentional error on
the part of the original implementation.
At the very least, the Javadocs need to change to reflect this behaviour.
The issue with changing the code is that people may already be relying on this
behaviour. All of the {{addXXX}} methods use Calendars and would be impacted.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246097#comment-13246097
]
Thomas Neidhart commented on LANG-796:
--
I like the idea somehow, but it would also mean to duplicate the signature of a
class, as all the methods in DateUtils are static.
Something that I have in mind, is to extract the current interface of DateUtils
into a separate class TBD. DateUtils would then provide two static members
DEFAULT and UTC, which instantiate the separate class TBD with the
corresponding timezones (TimeZone.getDefault() or TimeZone.getTimeZone(UTC)).
Additionally to mimick the current behavior, the existing static methods in
DateUtils would call the corresponding methods of DateUtils.DEFAULT.
Users can instantiate also a TBD instance by providing a custom timezone.
But this is maybe an overkill, the same can be achieved by altering the default
Timezone via TimeZone.setDefault. Although there are surely use-cases where
this is not possible or desirable (e.g. due to multi-threading).
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245250#comment-13245250
]
Thomas Neidhart commented on LANG-796:
--
I was still musing about this issue, and maybe adding an additional version
with a TimeZone parameter could make sense:
{noformat}
public static Date add(Date date, int calendarField, int amount, TimeZone tz) {
Calendar cal = Calendar.getInstance(tz);
cal.setTime(date);
cal.add(calendarField, amount);
return cal.getTime();
}
{noformat}
But to be consistent, this should be done for all methods (e.g. addDays,
addMonths, ..), and would definitely bloat the API.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245300#comment-13245300
]
Joerg Schaible commented on LANG-796:
-
What about creating UTCDateUtils instead that operates on UTC and is therefore
independent of any TZ? Then we have simply to properly document both types. We
could use a package private base class to share common functionality.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240283#comment-13240283
]
Nicola Barbiero commented on LANG-796:
--
That's the point: DateUtils.addDays receives in input a Date, that is an
absolute time, so it should not be influenced by DST. Using a Calendar
configured for the UTC timezone means to not use DateUtils.addDays, since there
is no overloading method that receives a Calendar in input.
As Thomas said, the method uses internally the default Calendar instance, that
is set to the local timezone of the server where the code is running, and this
is quite problematic in those time of cloud computing, because the code will
work differently if the server is located in a zone where DST is applied or not
(some countries do not implement any DST at all).
Summarizing, for me the issue is that the user of this method is affected by
the TimeZone but he has no way to set this TimeZone, because always the default
Calendar instance and the local timezone are used.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239466#comment-13239466
]
Adrian Crum commented on LANG-796:
--
The current behavior is correct. The result added one day. One day is NOT equal
to 8640 milliseconds - as you can see from the result.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239560#comment-13239560
]
Nicola Barbiero commented on LANG-796:
--
From http://docs.oracle.com/javase/6/docs/api/java/util/Date.html:
The class Date represents a specific instant in time, with millisecond
precision. [...] the Date class is intended to reflect coordinated universal
time (UTC) [...] Nearly all modern operating systems assume that 1 day = 24 ×
60 × 60 = 86400 seconds in all cases.
The concept of daylight saving time (DST) is not present in UTC, and UTC is
NEVER effected by DST, so a method that receives a Date in input and returns a
Date should never be effected by DST.
http://en.wikipedia.org/wiki/Coordinated_Universal_Time#Daylight_saving
The current behavior would be correct if working on Calendar objects, since a
Calendar takes in account the concept of DST.
By the way, even if the final choice will be to not change the current behavior
for this method, at least it should be better documented in its javadoc, to
avoid misuses and misunderstanding in its way of working.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239606#comment-13239606
]
Adrian Crum commented on LANG-796:
--
If you want to perform millisecond arithmetic, then I recommend you use long
values and avoid using the DateUtils class.
The JavaDocs seem clear to me - the method adds a day, not 8640
milliseconds.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239608#comment-13239608
]
Thomas Neidhart commented on LANG-796:
--
I had to deal with DST problems just recently myself:
The behaviour of DateUtils is perfectly valid if you consider your local
timezone. The method uses internally the default Calendar instance (that is set
to your local timezone) and is thus affected by DST. If you want to operate on
UTC dates only, use a Calendar configured for the UTC timezone.
It could be elaborated a bit more in the javadoc, so that people are aware of
the fact, but there is nothing wrong with it imho.
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*(8640), where 8640 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-_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 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 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 * 8640l);
}
--
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
