10:07 p.m.
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
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. 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:58 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Alejandro Guizar updated JBPM-1146:
-----------------------------------
Status: Coding In Progress (was: Open)
SVN / CVS Isolated Branch: jbpm_3_1_4_JBPM-1146
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
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. 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 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Alejandro Guizar updated JBPM-1146:
-----------------------------------
Attachment: jbpm-3.1.4.jar
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-3.1.4.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:13 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Alejandro Guizar updated JBPM-1146:
-----------------------------------
Assignee: JBoss QA Lead (was: Alejandro Guizar)
Status: QA In Progress (was: Coding In Progress)
Patch Instructions:
PATCH NAME:
JBPM-1146
PRODUCT NAME:
JBoss jBPM
VERSION:
3.1.4
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-3.1.4.jar to <jbpm-home>/build/
Run ant -f build.deploy.xml build.webapp in <jbpm-home>/ to rebuild the web
module
COMPATIBILITY:
no known issues
DEPENDENCIES:
none
SUPERSEDES:
none
SUPERSEDED BY:
none
CREATOR:
Alejandro Guizar
DATE:
5 Mar 2008
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-3.1.4.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
8:21 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Rajesh Rajasekaran updated JBPM-1146:
-------------------------------------
Due Date: 14/Mar/08
Assignee: Len DiMaggio (was: JBoss QA Lead)
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Len DiMaggio
Attachments: jbpm-3.1.4.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:35 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=comments#action_12402476 ]
Len DiMaggio commented on JBPM-1146:
------------------------------------
Test for fix: http://jira.jboss.com/jira/browse/JBPM-1137#action_12401650
1. cd build
2. ant test.jpdl
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Len DiMaggio
Attachments: jbpm-3.1.4.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
7:42 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=comments#action_12402541 ]
Len DiMaggio commented on JBPM-1146:
------------------------------------
test.jpdl does not exist as a target in 3.1.4 - in trying to run test.jbpm - I'm
seeing the system CPU go to 100% and the tests hang. (I'll try on a machine with more
CPU/memory.)
So - which tests do I want to run to recreate this problem? Thanks
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Len DiMaggio
Attachments: jbpm-3.1.4.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:48 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Ryan Campbell updated JBPM-1146:
--------------------------------
Status: Coding In Progress (was: QA In Progress)
Assignee: Alejandro Guizar (was: Len DiMaggio)
Alejandro,
Please tell us which test validates this bug fix, or how to otherwise verify the fix.
Thanks,
Ryan
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-3.1.4.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:48 a.m.
New subject: [JBoss JIRA] Commented: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=comments#action_12402840 ]
Alejandro Guizar commented on JBPM-1146:
----------------------------------------
The test case is org.jbpm.calendar.BusinessCalendarTest (1). As in JBPM-1137, the test
already existed; I committed new test methods to the patch branch.
jBPM 3.1.4 was tested by running org.jbpm.AllTests under Eclipse as opposed to running the
"test.jbpm" target in /build.xml. The Ant target does not run org.jbpm.AllTests;
instead, it searches for *Test.class files and runs them all as tests. For this reason,
tests not included in org.jbpm.AllTests were overlooked and some of them fail.
So you may want to modify the build file in your workspace to run org.jbpm.AllTests.
I've applied the required changes to the patch branch (2). Alternatively, just ignore
the errors that appear without the patch.
(1)
http://fisheye.jboss.com/browse/~br=jbpm_3_1_4_JBPM-1146/JBPM/jbpm.3/src/...
(2) http://fisheye.jboss.com/browse/~br=jbpm_3_1_4_JBPM-1146/JBPM/jbpm.3/buil...
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-3.1.4.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:44 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Alejandro Guizar updated JBPM-1146:
-----------------------------------
Assignee: JBoss QA Lead (was: Alejandro Guizar)
Status: QA In Progress (was: Coding In Progress)
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-3.1.4.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
8:29 p.m.
New subject: [JBoss JIRA] Assigned: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Ryan Campbell reassigned JBPM-1146:
-----------------------------------
Assignee: Len DiMaggio (was: JBoss QA Lead)
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Len DiMaggio
Attachments: jbpm-3.1.4.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
8:09 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=comments#action_12403221 ]
Len DiMaggio commented on JBPM-1146:
------------------------------------
Using the patched build.xml file - all the tests in the
org.jbpm.calendar.BusinessCalendarTest class pass.
FYI - I'm seeing the same results with/without the patch:
ant test
Buildfile: build.xml
compile.jbpm:
compile.identity:
compile.jbpm.test:
test.jbpm:
[junit] Running org.jbpm.AllTests
[junit] Tests run: 872, Failures: 1, Errors: 0, Time elapsed: 43.006 sec
[junit] Test org.jbpm.AllTests FAILED
[junitreport] Transform time: 54895ms
compile.identity.test:
test.identity:
[junit] Running org.jbpm.identity.xml.IdentityXmlParsingTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.255 sec
[junit] Tests run: 15, Failures: 0, Errors: 1, Time elapsed: 6.094 sec
[junit] TEST org.jbpm.identity.assignment.ExpressionAssignmentHandlerTest FAILED
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.287 sec
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.221 sec
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.015 sec
[junit] Tests FAILED
[junitreport] Transform time: 51983ms
test:
BUILD SUCCESSFUL
Total time: 2 minutes 47 seconds
Package org.jbpm.calendar
Name Tests Errors Failures Time(s)
BusinessCalendarTest 12 0 0 0.015
DayPartTest 3 0 0 0.005
DayTest 3 0 0 0.004
HolidayTest 2 0 0 0.004
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Len DiMaggio
Attachments: jbpm-3.1.4.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
8:11 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=comments#action_12403222 ]
Len DiMaggio commented on JBPM-1146:
------------------------------------
The checksums of the files are:
Running the full test suite with and without the patch:
d465bf07406c193aacf14185157989fa /opt/jbpm.3.patch/build/jbpm-3.1.4/build/jbpm-3.1.4.jar
d465bf07406c193aacf14185157989fa /opt/jbpm.3.patch/build/jbpm-3.1.4.jar
d465bf07406c193aacf14185157989fa /opt/jbpm.3.patch/build/jbpm.sar.dir/jbpm-3.1.4.jar
c663747f1ae5b06d0b1ded53be347ce9 /opt/jbpm.3/build/jbpm-3.1.4/build/jbpm-3.1.4.jar
c663747f1ae5b06d0b1ded53be347ce9 /opt/jbpm.3/build/jbpm-3.1.4.jar
c663747f1ae5b06d0b1ded53be347ce9 /opt/jbpm.3/build/jbpm.sar.dir/jbpm-3.1.4.jar
******************************
d465bf07406c193aacf14185157989fa /opt/jbpm-3.1.4.jar (the patched file)
******************************
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Len DiMaggio
Attachments: jbpm-3.1.4.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
8:14 p.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Len DiMaggio resolved JBPM-1146.
--------------------------------
Assignee: JBN Patch Team (was: Len DiMaggio)
Tests passed with this file:
d465bf07406c193aacf14185157989fa /opt/jbpm-3.1.4.jar (the patched file)
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-3.1.4.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
8:35 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Len DiMaggio updated JBPM-1146:
-------------------------------
Assignee: JBoss QA Lead (was: JBN Patch Team)
Status: QA In Progress (was: Pending Upload to Patch Repository)
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-3.1.4.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
8:40 p.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Len DiMaggio resolved JBPM-1146.
--------------------------------
Assignee: JBN Patch Team (was: JBoss QA Lead)
Tests were run with this file:
d465bf07406c193aacf14185157989fa /opt/jbpm.3.patch/build/jbpm-3.1.4.jar
d465bf07406c193aacf14185157989fa /opt/jbpm.3.patch/build/jbpm.sar.dir/jbpm-3.1.4.jar
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-3.1.4.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:37 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?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.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-3.1.4.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:01 p.m.
New subject: [JBoss JIRA] Commented: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=comments#action_12403938 ]
Frank Merenda commented on JBPM-1146:
-------------------------------------
This has been uploaded to:
https://support.redhat.com/jbossnetwork/restricted/softwareDetail.html?so...
I am commenting on the ticket now.
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBoss QA Lead
Attachments: jbpm-3.1.4.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:19 p.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Rajesh Rajasekaran resolved JBPM-1146.
--------------------------------------
Assignee: JBN Patch Team (was: JBoss QA Lead)
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-3.1.4.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:19 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Rajesh Rajasekaran updated JBPM-1146:
-------------------------------------
Status: Resolved (was: Pending Upload to Patch Repository)
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-3.1.4.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:56 a.m.
New subject: [JBoss JIRA] Reopened: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Thomas Diesler reopened JBPM-1146:
----------------------------------
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: JBN Patch Team
Attachments: jbpm-3.1.4.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:56 a.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1146) Leap Year Date Calculations (v3.1.4)
[ http://jira.jboss.com/jira/browse/JBPM-1146?page=all ]
Thomas Diesler resolved JBPM-1146.
----------------------------------
Resolution: Done
Assignee: Alejandro Guizar (was: JBN Patch Team)
Fix JBWS-1707
Leap Year Date Calculations (v3.1.4)
------------------------------------
Key: JBPM-1146
URL: http://jira.jboss.com/jira/browse/JBPM-1146
Project: JBoss jBPM
Issue Type: Support Patch
Components: Core Engine
Affects Versions: jBPM 3.1.4
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Attachments: jbpm-3.1.4.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
5890
days inactive
5918
days old
21 comments
7 participants
participants (7)
-
Alejandro Guizar (JIRA) -
Anonymous (JIRA)
-
Frank Merenda (JIRA)
-
Len DiMaggio (JIRA)
-
Rajesh Rajasekaran (JIRA)
-
Ryan Campbell (JIRA)
-
Thomas Diesler (JIRA)