You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When calculating a timer's expected next timeout, certain tests do not take into consideration leap years. So when running these tests on Feb 28, or Feb 29, the created test timer is configured to expire on Feb 29 of some year depening on the schedule's year and start attributes. The tests calculate the next timeout year to be the intersection of year and start attribute values, but some of these calculated years do not have Feb 29.
For example, all these failed tests have output as follows:
[TEST FAILED] testName=startAfterActualValues
Created a timer with expression year=2020 - 2032 month=2 dayOfMonth=29 dayOfWeek=* hour=5 minute=35 second=28 start=Sat Feb 28 05:35:29 EST 2026 end=null timezone=null
Compare expected nextTimeout Mon Mar 01 05:35:28 EST 2027, and actual nextTimeout Tue Feb 29 05:35:28 EST 2028
In the above test, the expected timeout (Mar 01, 2027) is actually wrong as the timer is set to expire on Feb 29. The actual timeout value is correct (Feb 29, 2028).
[TEST FAILED] testName=startAfterActualValues2
Created a timer with expression year=2020 - 2032 month=2 dayOfMonth=29 dayOfWeek=* hour=4 minute=57 second=42 start=Sat Feb 28 04:47:42 EST 2026 end=null timezone=null
Compare expected nextTimeout Sun Mar 01 04:57:42 EST 2026, and actual nextTimeout Tue Feb 29 04:57:42 EST 2028
In the above test, the expected timeout (Mar 01, 2026) is actually wrong as the timer is set to expire on Feb 29. The actual timeout value (Feb 29, 2028) is correct.
See one of the test methods that surgically set the year field on the expected timeout time:
/* * @testName: startAfterActualValues2 * * @test_Strategy: the start attr of the expression represents a time after * the first expiration. Verify that the timer does not start at the current * year; it should start a little later after the start date. For example, * * year=2009 - 2021 month=1 dayOfMonth=20 dayOfWeek=* hour=10 minute=33 * second=19 start Tue Jan 20 10:23:19 EST 2015 end null */publicvoidstartAfterActualValues2() {
intplusMinutes = 10;
Calendarcal = Calendar.getInstance();
intcurrentYear = TimerUtil.getForSchedule(Calendar.YEAR, cal);
DatecurrentDate = cal.getTime();
cal.add(Calendar.MINUTE, plusMinutes);
DatecurrentDatePlus = cal.getTime();
ScheduleExpressionexp = TimerUtil.getPreciseScheduleExpression(cal);
// the start time (excluding year) is before the scheduled timeDatestart = DateUtils.addYears(currentDate, WAIT_YEARS);
exp.start(start);
exp.year((currentYear) + " - " + (currentYear + WAIT_YEARS * 2));
Timertimer = createTimer(exp);
intstartYear = TimerUtil.getDateField(Calendar.YEAR, start);
DateexpectedNextTimeout = DateUtils.setYears(currentDatePlus, startYear);
verifyNextTimeout(expectedNextTimeout, timer);
passIfNoTimeout();
}
The text was updated successfully, but these errors were encountered:
When calculating a timer's expected next timeout, certain tests do not take into consideration leap years. So when running these tests on Feb 28, or Feb 29, the created test timer is configured to expire on Feb 29 of some year depening on the schedule's
year
andstart
attributes. The tests calculate the next timeout year to be the intersection ofyear
andstart
attribute values, but some of these calculated years do not have Feb 29.For example, all these failed tests have output as follows:
In the above test, the expected timeout (Mar 01, 2027) is actually wrong as the timer is set to expire on Feb 29. The actual timeout value is correct (Feb 29, 2028).
In the above test, the expected timeout (Mar 01, 2026) is actually wrong as the timer is set to expire on Feb 29. The actual timeout value (Feb 29, 2028) is correct.
The following are tests affected by this issue:
See one of the test methods that surgically set the year field on the expected timeout time:
The text was updated successfully, but these errors were encountered: