The python rrdtool output is shifted by one step (here 300 seconds) in the past comparing
to the original RRD maintainer version of rrdtool (Package: rrdtool, Version: 1.7.2-3+b7)
from https://oss.oetiker.ch/rrdtool/

Sample of `rrdtool dump /var/local/mrtg/rrd/ROCKF/RockB/xxx.rrd'

<!-- 2023-06-04 07:30:00 CEST / 1685856600 --> <row><v>6.8145444444e+00</v><v>1.1404103111e+03</v></row>
<!-- 2023-06-04 07:35:00 CEST / 1685856900 --> <row><v>6.3194111111e+00</v><v>1.3107397333e+03</v></row>
<!-- 2023-06-04 07:40:00 CEST / 1685857200 --> <row><v>6.9399666667e+00</v><v>1.3779331111e+03</v></row>

Sample of rrdtool.fetch('/var/local/mrtg/rrd/ROCKF/RockB/xxx.rrd','MAX','1685943000')

(1685856600, 1685943300, 300),
('ds0', 'ds1'),
[ (6.319411111111111, 1310.7397333333336),
  (6.939966666666666, 1377.9331111111112),
  (6.385982274247492, 1407.4662690078037),
  ...
]

The python3-rrdtool is not very clear how to manage the first value with the timestamps
it returns (https://pythonhosted.org/rrdtool/usage.html#functions<https://pythonhosted.org/rrdtool/usage.html#functions>) but the number of steps
it gives (ie 290 values - not listed here -) matches the start and end values (here
1685856600 and 1685943300) by 290 increments indicating a first value of 6.319411111111111
at 1685856600 timestamp (which is not what rrdtool returns).

Moreover, python3-rrdtool returns one or two records ahead (in the future) sometimes which
all are to a correct none value confirming the bug.

Best regards,