[rrd-users] Timezone problems

[David Vickers]

Tom,

I had the same problem, which is especially noticable if you are generating 
graphs that have a low resolution, ie., more than one pixel per data point. 
The X axis outputs ok since it seems to use localtime calls for formatting but
the "bars" of a stack graph formatted to represent "days" are all out by ten 
hours (where I live is GMT+10).  The only solution I have found is what you 
have suggested, ie., to add ten hours to the time when running rrd_update 
and then produce all graphs by setting TZ to GMT. This produces correct 
output for my timezone but is not what I would call a neat solution. I don't like 
having to store data that has been tailored for one particular timezone. 

I went through the mail archive and Tobi, at one point, suggested the use of rrd_graph
and the PRINT command to produce daily consolidations in the correct timezone.
I tried  this and could produce individual values for each 24 hour period but you can't
graph it using rrd_graph unless you feed it back into an rrd with a step of 86400. Of
course if you do that and send an update at 00:00 localtime, rrd_update interpolates 
the data since it is only expecting updates at 00:00 GMT and the resulting graphs
are incorrect.

Anyone have a simple solution for this?


------------------------------------------------------------------
David Vickers
INSU - CITEC
David.Vickers at citec.com.au
------------------------------------------------------------------

>>> "Honermann Tom A." <TA.Honermann at hosp.wisc.edu> 07/27 7:57 am >>>
>2 things:
>
>1st, I've been working on a set of scripts that go out over ssh (could use
>rsh) to a host, supplies a shell script to run (fsu, which stands for File
>System Utilization) which gets the disk capacity, space in use, space
>modified within the last 24 hours, number of files changed within the last
>24 hours, etc...brings that info back and throws it into an rrd.  This is
>still quite untested.  I am using it on Linux and have tested it (slightly)
>on AIX.  Some support for Solaris is in it, but I don't think that currently
>works.  If anyone is interested in playing with this, let me know.
>
>2nd, I have it setup to run once a day here (The resolution of the data is
>only 24 hours).  There is a problem with it that I am trying to work out
>right now however.  The problem is this: rrd stores time in seconds since
>Jan 1, 1970 00:00:00 GMT.  My time zone is CST6CDT which is 21600 seconds
>behind GMT during CST and 18000 seconds behind GMT during CDT.  Rrd does
>this somewhat neat thing of calculating time slots within the rrd by using
>the remainder of a division of the number of seconds since the epoch in GMT
>time and the update time so that the time stamps are stored in a nice, neat
>format rounded to the nearest nice number in terms of the step time
>(17:05:00 instead of 17:07:22 when a step of 300 is used).  This works great
>until the time step starts getting over 3600 seconds (1 hour).  At this
>point, some weird things happen, for example:  I am trying to enter in some
>information at midnight every night.  (The scripts I run necessitate it
>being done during off hours) so I create my rrd with a step of 86400, and a
>start time of Jun 22, 1999 00:00:00 CDT.  (Note the CDT)  Rrd does the
>rounding thing to come up with nice times and forces the start time to Jun
>21, 1999 19:00:00 GMT.  (Note, these two times are equivalent)  When I try
>and graph the results then, the data looks as though it were gathered at
>19:00 hours of the day before instead of at midnight.
>
>I'm just realizing right now, that probably the right way for me to fix this
>now is to adjust all my time entries for GMT times.  That means always
>having to specify what time slot should be used in the script which does the
>update, or finding a way to specify an update time relative to GMT.  Doing
>this however means that the time stored does not reflect the _actual_ time
>the data was taken.
>
>Is anyone else having problems with the step resolution and time zones?  I
>suspect that the remainder time stamp tuning trick should be limited in
>resolution to hours so as not to interfere with people's differing time
>zones.  Comments?
>
>
>---------------------------------------------------------------
>Tom Honermann                  UW Health - UWHC
>Systems Analyst                Information Systems
>ta.honermann at hosp.wisc.edu     610 North Whitney Way
>Phone: (608) 265-3925          Suite 4200
>Fax:   (608) 265-3920          Madison, WI  53705
>
>---------------------------------------------------------------


--
* To unsubscribe from the rrd-users mailing list, send a message with the
  subject: unsubscribe to rrd-users-request at list.ee.ethz.ch