Graphite

intermittent time zone

Asked by bobemoe

I have set the time_zone in settings.py and local_settings.py to 'Europe/London' and I thought that it had had the desired affect, however a little later on it seems to have reverted back to the default. Further investigation reviled that it seems to be quite random if the graph is rendered displaying the correct timezone or not, to the extent that I actually had the times changing between the correct and what I assume to be the default every other refresh of the same graph!

I am collecting data at 1 sec intervals, which is the only thing I can think that could have changed anything between refreshes.

Any ideas what could be causing this?

Thanks.

Question information

Language:
English Edit question
Status:
Answered
For:
Graphite Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
chrismd (chrismd) said : 		#1

Definitely a bug, handling timezones turns out to be quite tricky in python. The current implementation uses a clever hack to make it work but I bet that its causing your issue. I think an easy solution would be to allow the user to specify the timezone offset explicitly and also to support named timezones through an optional dependency on something like pytz. I'll create a bug to track this.

Revision history for this message
Pete Emerson (pete-appnexus) said : 		#2

What did you do to get rid of the alternating display of the data once you reverted your settings? I've got the same problem right now.

Pete

Revision history for this message
chrismd (chrismd) said : 		#3

Unfortunately Bug #528228 is still open and I do not know of any work arounds yet. I'm pretty sure I know where the problem lies though, in trunk look in webapp/graphite/render/glyph.py near the bottom in a funtion called tz_difference. It is supposed to calculate the current timezone's offset from GMT. The current implementation changes the TZ environment variable, calls tzset(), calculates the difference between gmtime and localtime, and then resets the TZ variable and .... hm... wow. It doesn't call tzset() a second time, maybe that's the problem? I'll take a look at this again later tonight, in the mean time feel free to try adding another tzset() call at the end of tz_difference and see if that helps.

Can you help with this problem?

Provide an answer of your own, or ask bobemoe for more information if necessary.

To post a message you must log in.