Timezone and absolute time range

[torkelo]

I am unable to get the tz parameter to have any effect on the time range filter. It seems to only change the time axis on the rendered image.

Example:

/render?from=07:00_20140226&until=08:00_20140226&width=400&height=250&target=carbon.agents.graphite.metricsReceived

Here I do not have a tz parameter, the from parameter 07:00_20140226 is handled with the default timezone (set in local_settings.py) and the time axis is also shown in the default timezone (Europe/Berlin).

Example2:

/render?from=07:00_20140226&until=08:00_20140226&width=400&height=250&target=carbon.agents.graphite.metricsReceived&tz=America/New_York

This image shows the same data, but the time axis shows time in America/New_York timezone, I would expect that the time range "from" parameter also would be parsed as America/New_York and that the graph would change to reflect a completely different time range.

The problem I have is with Grafana, an alternate frontend for graphite. Users located in different time zones cannot zoom (i.e use absolute time ranges). I would like to send the from and until parameter in their local time zone and have graphite translate it.

Looking at render/views.py it looks like from and until is parsed using parseATTime but somehow it is not having any effect when fetching data for the series.

[torkelo]

Anyone have any feedback on this or idea why fz is not affecting the data shown but only the time labels?

[jippi]

👍

[brutasse]

FYI I have fixed this issue in graphite-api.

See brutasse/graphite-api@c8854f5

from/until are resolved using the provided timezone and legends are displayed in the requested timezone as well.

[torkelo]

@brutasse nice. will test it.

[Comradin]

Any chance, this will be fixed in 0.9.13?

[deniszh]

@Comradin,
IIRC it's already done in #989 and later fixes.

[Comradin]

Hmm, but why is this issue then still open if it is fixed in master?
Any news on when 0.9.13 will finally arrive?

[deniszh]

Good question. Maybe nobody checked if issue is really gone in master / 0.9.x ?
@torkelo, could you please test it?

And please note that master and 0.9.x are different branches.

[obfuscurity]

@torkelo would you be so kind as to test this against 0.9.x and see if the issue is resolved for you?

[torkelo]

@obfuscurity seems to be working. This is not an issue for Grafana any more, as Grafana switched to using epochs in the from and until parmas

[obfuscurity]

Thanks @torkelo.

[Dieterbe]

i'm looking into this more , using graphite 1.0.1 and I can report that while this bug is indeed fixed (e.g. date specification is interpreted in the timezone) when specifying timezone with a HH:MM_YYYMMDD pattern, it does not work when using other at-style patterns, such as noon. see examples below. (default TZ is set up to UTC)

patterns it does work with.

target=carbon.agents.b2dd5129e459-a.updateOperations&from=08:00_20170706&tz=America/New_York

target=carbon.agents.b2dd5129e459-a.updateOperations&from=08:00_20170706

patterns it does not work with

as originally reported, here the TZ just controls the timestamps returned, it does not control how the data specification is interpreted (thus, which data is fetched)
target=carbon.agents.b2dd5129e459-a.updateOperations&from=noon&tz=America/New_York

target=carbon.agents.b2dd5129e459-a.updateOperations&from=noon