[rrd-users] Re: RRDtool "GMT-centric" problem?

[Alex van den Bogaerdt]

(note: IMO we should move this discussion to rrd-developers. Agree by
sending replies to there, not here).


For those of you who need to create and process RRDs in local time, not
UTC time:

(by the way, as usual, mode IMHO is set to on)

I think it is safe to say that RRDtool considers a day to be a period
of 24 hours, not necessarily starting or ending at midnight, whereas
you guys need a day to be defined as a period from midnight to midnight.
This is a major difference.

Either:
- Change the whole concept of RRDtool
- Move your computer to UTC

This last option is not so ridiculous at it seems, however you do need
a separate computer for it and it will get you into trouble when doing
stuff such as NTP.  This is because your computer will run on the wrong
time.  You need to set the clock (once) to local time and thereby you
are, well, lying.  It will provide a solution to the original problem
if I understand it right.  It won't be perfect as DST changes are not
happening.  More on this at the end.

Without trying -so just to contribute for others to experiment- Have you
already tried to modify the timestamps you are feeding to RRDtool?
I think this will emulate the second option as described above.

Assume Europe, midnight, no DST in effect.  Time will be 948236400.
For UTC, this will be 23:00.  Add 3600 to 948236400 to get UTC midnight.
Use this new timestamp (948240000) to update the database.

When extracting data from the database, again UTC should be used.
RRDtool will try and compensate for the timezone so this should be set
to UTC.  (TZ=UTC rrdtool graph --start 948240000 --end 948326400 ...)

This won't be perfect when changing to/from DST.  Same for local time.
In Europe it will be 2:30 twice on the last sunday of October and it
won't be 2:30 at all on the last sunday of March.  RRDtool can handle
this because it does not use timezones for storing data nor for graphing.
It only uses the timezones for the horizontal axis's label.

If you store the samples in local time, you will be storing 2:00 twice
or never.  In the first case, you get an error, in the second case you
get a gap (which might be filled, depending on the DS settings).
In both cases, averages won't work properly because a day is not exactly
24 hours.

Working in UTC is the only proper solution.  The workarounds as described
above all have their advantages and disadvantages.

Changing the whole concept of RRDtool is not an option (remember the
IMHO from above?) as this is a major change in the concept of RRDtool.
It will introduce new bugs (which will be removed again undoubtly) and
it will be worse to understand.  Also, the number of user errors will
increase.  Without DST there is no problem; trying to cover for DST
changes while not just avoiding them (UTC) will always be a cludge.

Regards,
-- 
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users