Bug ID: 18356
Summary: Prediction pattern wrong, skips years, for some year
Change sponsored?: ---
Priority: P5 - low
Assignee: [hidden email] Reporter: [hidden email] QA Contact: [hidden email] CC: [hidden email]
Set a frequency with:
Issues per unit: 9
Units per issue: 1
Issues per unit: 12
Units per issue: 1
Notice the prediction pattern works for about 1 cycle, then crossed to next
year, then jumps a year:
This patch deals with tests for yearly frequencies.
 Adjust mixup of units/issues in a description.
 Add testing +2 years on 29-2 of leap year for freq 1 issue/2 years.
 Add tests for freq 9 issues/year. We also include testing the operation
of rounding dates to first acquisition day and month when close enough.
 Two subtests are provided for irregular frequencies (very trivial) and
for year frequencies (with three specific test cases).
 Run t/db_dependent/Serials/GetNextDate.t
 Run t/db_dependent/Serials/GetFictiveIssueNumber.t
Note: Without the second patch both tests should fail. This shows the need
of the adjustments in the second patch.
The problem as described on BZ 18356 is a combination of an error in
GetFictiveIssueNumber and GetNextDate for unit==year.
In GetFictiveIssueNumber the year should be decreased by one if you have
more units per year and you did not yet reach firstacqui day and month.
This affects calculations in GetNextDate with irregularities.
In GetNextDate the Add_Delta_YM calculation should be applied only to
frequencies based on years per unit.
In the case of multiple units per year we calculate the number of days to
add. And if we have reached the end of a year cycle, we 'round' up to
firstacqui day and month as long as we are close enough. Otherwise we just
add the number of calculated days, since we can safely assume that the
publish dates have been adjusted manually.
 Verify that both GetNextDate.t as well as GetFictiveIssueNumber.t pass.
 Look at the prediction pattern for a few frequencies.
For example: 1 iss/y, 1 iss/2y, 5 iss/y.