Some from and until time references in render API do not work as documented, some future times work and some do not

[kamaljain]

Being a very new user of Graphite, it is possible that this is purely user (my) error, but I have reviewed the documentation and also done some testing.

The documentation for the render API states that from and until query values can use human-friendly expressons like "6pm+yesterday" and "noon+today". The latter form works fine, but the former always throws an error.

For example, this works:
...&from=noon+today&until=noon+tomorrow...

But this fails:
&from=4pm+today&until=noon+tomorrow
with this error:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/django/core/handlers/base.py", line 111, in get_response
response = callback(request, _callback_args, *_callback_kwargs)
File "/opt/graphite/webapp/graphite/render/views.py", line 51, in renderView
(graphOptions, requestOptions) = parseOptions(request)
File "/opt/graphite/webapp/graphite/render/views.py", line 264, in parseOptions
untilTime = parseATTime(queryParams['until'], tzinfo)
File "/opt/graphite/webapp/graphite/render/attime.py", line 41, in parseATTime
return tzinfo.localize(parseTimeReference(ref), daylight) + parseTimeOffset(offset)
File "/opt/graphite/webapp/graphite/render/attime.py", line 115, in parseTimeReference
raise Exception, "Unknown day reference"
Exception: Unknown day reference

Similarly, this type of error occurs with only historical from/until references as well if trying to use a time like "6pm" or "9am", but the friendly name "noon" works - other friendly names like "teatime" also fail the same way.

[esc]

This might be related: using relative references into the future might also be bust:

&until=+2d

Leads to:

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/django/core/handlers/base.py", line 115, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
  File "/opt/graphite/webapp/graphite/render/views.py", line 48, in renderView
    (graphOptions, requestOptions) = parseOptions(request)
  File "/opt/graphite/webapp/graphite/render/views.py", line 287, in parseOptions
    untilTime = parseATTime(queryParams['until'], tzinfo)
  File "/opt/graphite/webapp/graphite/render/attime.py", line 43, in parseATTime
    return tzinfo.localize(parseTimeReference(ref), daylight) + parseTimeOffset(offset)
  File "/opt/graphite/webapp/graphite/render/attime.py", line 117, in parseTimeReference
    raise Exception("Unknown day reference")
Exception: Unknown day reference

[fjorgemota]

@esc

Try to use the URL encoded +, which is %2B actually.

Note that this dont solve the problem of allowing Graphite to show data in the future, something that I need and want to know too (for allowing visibility of goals in graph with multiple data series (with some goals, effectively)). See the issue that I opened at graphite-project/whisper#68

[esc]

@fjorgemota yeah, I think that is what I ended up doing (using %2B instead of +.

[Dieterbe]

with the latest graphite version (1.0.1) this trick seems to no longer work, getting the same error again. I tried + , %2B, quoted, unquoted, with curl and with browser, with space instead of plus, etc.
(note i believe curl/browser should convert + to %2B automatically in the background)
like originally reported, with curl until=noon+tomorrow works fine but until=6pm+tomorrow (or any other variant using %2B etc) does not.

[DanCech]

until=6:00pm+tomorrow will work, because graphite (currently) looks for X:XXpm. In general the parsing is pretty rigid about acceptable formats and could be made a lot more flexible.

Also note that + is correct here because it will be url-decoded to a space (until=6:00pm_tomorrow is also supported, as are until=6:00pm,tomorrow and until=6:00pmtomorrow). until=6:00pm%2Btomorrow is not correct because it will decode to 6:00pm+tomorrow and +tomorrow isn't a valid offset.

[DanCech]

Side note: until=+2d doesn't work because it decodes to <space>2d, which isn't a valid specification. until=%2B2d decodes to +2d and is thus valid (same thing as now+2d).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.