[rrd-developers] daily PDP points misaligned in non-GMT timezones

[Peter Payne]

Development bug/request.

Let's say I want to poll a value once per day, and generate graphs that
display a value for each day over a month.

Now let's assume I live somewhere in the world that is not in GMT.

I create my rrd file:

  rrdtool create tmp.rrd  --start 1121436000 --step 86400
RRA:MAX:0.5:1:40 DS:mys:GAUGE:1:U:U

Now you may ask, what is 1121436000? It is:
  Sat Jul 16 00:00:00 2005 GMT+1000

Because I started my rrdtool file at midnight, I expect my 24 hour
segments (86,400 seconds) to run from midnight to midnight every day.
But I am wrong.

Investigation of the rrd file shows that:

  rrdtool info tmp.rrd

  ds[mys].unknown_sec = 50400

How can this be? It implies that the data points are running from 10AM
to 10AM instead of midnight to midnight. Very suspicious!

The problem is littered throughout rrd files, but inspection of
rrd_create.c will immediately light up the issue:

  [rrd_create.c, line 256 (v1.0.49)]
    rrd->pdp_prep->scratch[PDP_unkn_sec_cnt].u_cnt =
        rrd->live_head->last_up % rrd->stat_head->pdp_step;

Whoops, looks like any attempt to have a PDP point that doesn't
precisely align (or mod into) 1 Jan 1970 00:00 GMT is going to be
warped.

I'm surprised no one in the world has had this issue with daily points.
Of course there's no problem if someone is using 1-hour or 5-minute
points because they all align nicely with 1 Jan 1970 00:00 GMT. But
daily points will be messed up for any timezone other than GMT.

POSSIBLE SOLUTION
Create a static value in the header called "pdp_offset". This is
calculated when the file is created and assumes that the starting time
is a PDP boundary, and that all PDPs will be aligned from that point
onwards. It is the behaviour I would naturally expect, anyway.

NASTY NASTY NASTY SOLUTION
I really don't want to have to do this :(:( but another solution would
be to break up my 24 hour value into 1 hour points and plot all my
points as 1-hr points. But this is doing things the hard way when
RRDTool could make it easier (and more "pure").

OK, thanks for listening.

Peter Payne
Sydney, Australia.


--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-developers
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi