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

[steve rader]

 > From: Alex van den Bogaerdt
 > 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.  

A change over to GMT (eg setting clock to GMT or using TZ=GMT) will
display "yesterday" has "yesterday GMT".

If I want to generate graphs that answer the question "How many
web hits the server handle yesterday" then "yesterday" needs to be
"yesterday localtime", so a change over to GMT will not help.

I think you are suggesting some human engineering: convincing folks
to think of "yesterday" as "yesterday GMT".  That doesn't address
the problem because I can't (or rather don't want to) convince folks
'round here to think in GMT.

 > 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.

IMHO, having "web hits served yesterday" off by an hour for
part of the year is a reasonable situation.  So I think having
GMT plus a single offset is a dandy solution.

 > 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.

I don't think the GMT plus a single offset is a major change.  (If it
was a major change to RRDtool, I think Tobi would have really balked
at the idea. =:)

Anyhow, I don't really care too much, because the workaround we've
developed works well and I don't think larger RRDs is an problem.

later
steve
- - -
systems guy
wiscnet.net

--
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