[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)

2012-03-28 Thread Nicola Barbiero (Commented) (JIRA)

[ 
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)

2012-03-27 Thread Nicola Barbiero (Commented) (JIRA)

[ 
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