6:34 p.m.
Leap Year Date Calculations
---------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Tom Baeyens
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb.
Durations that are not expressed in months or years work correctly under the current
model. Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February 29,
2008. Every day has the same duration even on leap years.
The presentation layer is responsible of converting the milliseconds in a Date to a
suitable representation in the calendar system. The Java APIs are all aware of leap years,
so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day.
To fix this, our Duration class has to preserve the original unit of time instead of
converting to milliseconds up front. Then we can do the following.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:36 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Assignee: Alejandro Guizar (was: Tom Baeyens)
Leap Year Date Calculations
---------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb.
Durations that are not expressed in months or years work correctly under the current
model. Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years.
The presentation layer is responsible of converting the milliseconds in a Date to a
suitable representation in the calendar system. The Java APIs are all aware of leap years,
so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day.
To fix this, our Duration class has to preserve the original unit of time instead of
converting to milliseconds up front. Then we can do the following.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:37 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Attachment: jbpm-jpdl.jar
uploading the patched jar
Leap Year Date Calculations
---------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb.
Durations that are not expressed in months or years work correctly under the current
model. Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years.
The presentation layer is responsible of converting the milliseconds in a Date to a
suitable representation in the calendar system. The Java APIs are all aware of leap years,
so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day.
To fix this, our Duration class has to preserve the original unit of time instead of
converting to milliseconds up front. Then we can do the following.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:39 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Status: Coding In Progress (was: Open)
SVN / CVS Isolated Branch: jpdl_3_2_2_JBPM-1137
Leap Year Date Calculations
---------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb.
Durations that are not expressed in months or years work correctly under the current
model. Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years.
The presentation layer is responsible of converting the milliseconds in a Date to a
suitable representation in the calendar system. The Java APIs are all aware of leap years,
so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day.
To fix this, our Duration class has to preserve the original unit of time instead of
converting to milliseconds up front. Then we can do the following.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:03 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Assignee: JBoss QA Lead (was: Alejandro Guizar)
Status: QA In Progress (was: Coding In Progress)
Patch Instructions:
PATCH NAME:
JBPM-1137
PRODUCT NAME:
JBoss jBPM
VERSION:
3.2.2
SHORT DESCRIPTION:
Date calculations are now delegated to java.util.Calendar whenever
possible
LONG DESCRIPTION:
Before, date calculations assumed months and years were exactly 30 and
365 days long respectively. With this fix, the actual durations of
concrete months and years will be taken into account. This is because
addition of durations to time instants will be delegated to the
java.util.Calendar class.
MANUAL INSTALL INSTRUCTIONS:
Copy jbpm-jpdl.jar to <jbpm-home>/
Add jbpm-jpdl.jar to <jbpm-home>/deploy/jbpm-console.war under WEB-INF/lib/
Add jbpm-jpdl.jar to <jbpm-home>deploy/jbpm-enterprise.ear under lib/
COMPATIBILITY:
no known issues
DEPENDENCIES:
none
SUPERSEDES:
none
SUPERSEDED BY:
none
CREATOR:
Alejandro Guizar
DATE:
3 Mar 2008
Leap Year Date Calculations
---------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb.
Durations that are not expressed in months or years work correctly under the current
model. Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years.
The presentation layer is responsible of converting the milliseconds in a Date to a
suitable representation in the calendar system. The Java APIs are all aware of leap years,
so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day.
To fix this, our Duration class has to preserve the original unit of time instead of
converting to milliseconds up front. Then we can do the following.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:14 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Description:
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February 29,
2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
was:
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb.
Durations that are not expressed in months or years work correctly under the current
model. Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February 29,
2008. Every day has the same duration even on leap years.
The presentation layer is responsible of converting the milliseconds in a Date to a
suitable representation in the calendar system. The Java APIs are all aware of leap years,
so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day.
To fix this, our Duration class has to preserve the original unit of time instead of
converting to milliseconds up front. Then we can do the following.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
Leap Year Date Calculations
---------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:05 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Summary: Leap Year Date Calculations (v3.2.2) (was: Leap Year Date Calculations)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:58 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Attachment: (was: jbpm-jpdl.jar)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:04 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Attachment: jbpm-jpdl.jar
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:14 a.m.
New subject: [JBoss JIRA] Assigned: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Rajesh Rajasekaran reassigned JBPM-1137:
----------------------------------------
Assignee: Jiri Pechanec (was: JBoss QA Lead)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Jiri Pechanec
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:08 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=comments#action_12401650 ]
Alejandro Guizar commented on JBPM-1137:
----------------------------------------
Yes, there is. After checking out the branch, do the following:
1. cd build
2. ant test.jpdl
I've already tested against HSQL. It'd be great if our other supported databases
could be tested as well.
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Jiri Pechanec
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:21 p.m.
New subject: [JBoss JIRA] Assigned: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Rajesh Rajasekaran reassigned JBPM-1137:
----------------------------------------
Assignee: Rajesh Rajasekaran (was: Jiri Pechanec)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Rajesh Rajasekaran
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:01 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=comments#action_12402549 ]
Rajesh Rajasekaran commented on JBPM-1137:
------------------------------------------
Alejandro
Just wanted to confirm a few things.
Running test.jpdl runs these 905 tests. Is that all?
[junit] Running org.jbpm.AllTests
[junit] Tests run: 905, Failures: 0, Errors: 0, Time elapsed: 88.214 sec
Also we test patches by building from the release branch and then replace with the
attached patch jar, we do not use the patch branch (jpdl_3_2_2_JBPM-1137) directly.
The test target kept rebuilding the jpdl jar replacing the patched one that i copied,
hence i had to disable the build part in the build files.
For patch testing, we do not cover multiple databases (this is covered as part of SOA
platform testing), unless the patch directly affects database.
Can you tell me if there is any way or testcase to test this leap year date calculations?
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Rajesh Rajasekaran
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Ryan Campbell updated JBPM-1137:
--------------------------------
Status: Coding In Progress (was: QA In Progress)
Assignee: Alejandro Guizar (was: Rajesh Rajasekaran)
Need feedback from Alejandro.
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:02 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=comments#action_12402835 ]
Alejandro Guizar commented on JBPM-1137:
----------------------------------------
The test case is org.jbpm.calendar.BusinessCalendarTest (1). This test case already
existed in the release tag; I added new test methods and committed them to the patch
branch. The release tag has 905 tests (as you found) while the patch branch has 915.
(1)
http://fisheye.jboss.com/browse/~br=jpdl_3_2_2_JBPM-1137/JBPM/jbpm.3/jpdl...
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:44 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Alejandro Guizar updated JBPM-1137:
-----------------------------------
Assignee: JBoss QA Lead (was: Alejandro Guizar)
Status: QA In Progress (was: Coding In Progress)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:27 p.m.
New subject: [JBoss JIRA] Assigned: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Ryan Campbell reassigned JBPM-1137:
-----------------------------------
Assignee: Rajesh Rajasekaran (was: JBoss QA Lead)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Rajesh Rajasekaran
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:09 p.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Rajesh Rajasekaran resolved JBPM-1137.
--------------------------------------
Assignee: JBN Patch Team (was: Rajesh Rajasekaran)
Verified patch and related test cases.
No regressions found.
md5sum:
4d96dfe067f6247883126e8c879bc18d jbpm-jpdl.jar
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:35 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Assignee: JBoss QA Lead (was: JBN Patch Team)
Status: QA In Progress (was: Pending Upload to Patch Repository)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:43 a.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Rajesh Rajasekaran resolved JBPM-1137.
--------------------------------------
Assignee: JBN Patch Team (was: JBoss QA Lead)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:59 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Assignee: JBoss QA Lead (was: JBN Patch Team)
Status: QA In Progress (was: Pending Upload to Patch Repository)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:01 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=comments#action_12403937 ]
Frank Merenda commented on JBPM-1137:
-------------------------------------
This has been uploaded to:
https://support.redhat.com/jbossnetwork/restricted/softwareDetail.html?so...
commenting on the ticket now.
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:19 p.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Rajesh Rajasekaran resolved JBPM-1137.
--------------------------------------
Assignee: JBN Patch Team (was: JBoss QA Lead)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:19 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Rajesh Rajasekaran updated JBPM-1137:
-------------------------------------
Status: Resolved (was: Pending Upload to Patch Repository)
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:58 a.m.
New subject: [JBoss JIRA] Reopened: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Thomas Diesler reopened JBPM-1137:
----------------------------------
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:58 a.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1137) Leap Year Date Calculations (v3.2.2)
[ http://jira.jboss.com/jira/browse/JBPM-1137?page=all ]
Thomas Diesler resolved JBPM-1137.
----------------------------------
Resolution: Done
Assignee: Alejandro Guizar (was: JBN Patch Team)
Fix JBWS-1707
Leap Year Date Calculations (v3.2.2)
------------------------------------
Key: JBPM-1137
URL: http://jira.jboss.com/jira/browse/JBPM-1137
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-jpdl.jar
Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There
might be issues around the end of Feb. The problem is characterized as follows. Under the
current model, durations that are not expressed in months or years work correctly.
Consider the following expression.
endDate = new Date(startDate.getTime() + interval);
If startDate is February 28, 2008 and interval is 1 day, then endDate will be February
29, 2008. Every day has the same duration even on leap years. The presentation layer is
responsible of converting the milliseconds in a Date to a suitable representation in the
calendar system. The Java APIs are all aware of leap years, so this is covered as well.
The situation is different for months and years. If the interval above was 1 year, then
endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate
has shifted backwards one day. To fix this, the Duration class has to preserve the
original unit of time instead of converting to milliseconds up front. Calculation of
endDate can then be delegated to java.util.Calendar as follows.
startCalendar = Calendar.getInstance();
startCalendar.setTime(startDate);
startCalendar.add(unit, interval);
endDate = startCalendar.getTime();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5885
days inactive
5930
days old
25 comments
6 participants
participants (6)
-
Alejandro Guizar (JIRA) -
Anonymous (JIRA)
-
Frank Merenda (JIRA)
-
Rajesh Rajasekaran (JIRA)
-
Ryan Campbell (JIRA)
-
Thomas Diesler (JIRA)