[pmg-devel] [PATCH pmg-api 2/2] fix #1974: postscreen_stat_graph: go through all entries

[Wolfgang Bumiller]

When the GUI requests the values for a whole month
containing a DST switch it will request a range a little
longer or shorter than a month, eg. 31.04166 days for
October 2018 in CET.

Since we use integer math to calculate the number of entries
we expect, the database then returns one more value than
expected, and we forget to fill in the last time value.

For example, requesting Oct. 2018 from CET causes the
equivalent of this query:

  # pmgsh get /statistics/rejectcount --starttime=1538344800 --endtime=$[1541026800] --timespan=86400
  400 Result verification failed
  [31].time: property is missing and it is not optional

Note that:

  $ echo $[(1541026800-1538344800) / (60*60*24.)]
  31.041666666666668

This also happens when for example taking the working range
for the month and simply subtracting 1 second from the
end-time. Our division will then round down by a day while
the database timestamps still cause that day to be included
in the result.
---
 PMG/Statistic.pm | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/PMG/Statistic.pm b/PMG/Statistic.pm
index ac9473f..c2b103f 100755
--- a/PMG/Statistic.pm
+++ b/PMG/Statistic.pm
@@ -780,13 +780,14 @@ sub postscreen_stat_graph {
     my $sth = $rdb->{dbh}->prepare($cmd);
     $sth->execute ();
 
+    my $max_entry = int(($to - $from) / $span);
     while (my $ref = $sth->fetchrow_hashref()) {
-	$res->[$ref->{index}] = $ref;
+	my $i = $ref->{index};
+	$res->[$i] = $ref;
+	$max_entry = $i if $i > $max_entry;
     }
 
-    my $c = int (($to - $from) / $span);
-
-    for my $i (0..$c) {
+    for my $i (0..$max_entry) {
 	$res->[$i] //= { index => $i, rbl_rejects => 0, pregreet_rejects => 0};
 
 	my $d = $res->[$i];
-- 
2.11.0