Plot metrics in the future

I did some work on this code recently (https://github.com/graphite-project/whisper/pull/6) and noticed that some of the "magic" adjustments of from/until times seem a bit inconsistent. I don't think there is a single "philosophy" that explains all cases, I had the impression most of these adjustments were added at one point without thinking too much about it.

My opinion on this is: whisper should only error if from > until. in all other cases (an until date in the future, even a from date in the future) whisper should IMHO just return whatever the user asked for. it's the caller's responsability to use sensible/correct from/until dates.

magically altering from/until dates:
* makes things less clear (if you're debugging a web interface and you see a request with a certain from/until date, you should be able to know that's what whisper will return you, without diving in the whisper code to find out all the special conditions)
* makes things less flexible (if you try to prevent users from doing dumb things, you also prevent them from doing clever things), as this example shows
* introduces uncertainty . different callers might have different expectations and assumptions.

in addition to what I already said, I can also imagine use cases where a user might want to store datapoints for future dates, on purpose. for example output of cpu intensive future predictions, or deadlines or numeric tresholds that will need to be met

While there's a case for storing future data, I dont think there'd be a way to make this sanely work with whisper as it's designed. Since these files are fixed size and written with rolling-over offsets, writing to the future will overwrite data in the past. Ex: you have a whisper file with 30 day retention - if you write data 1 day in the future, you'll overwrite the data from 30 days ago. It's more confusing if you have multiple retentions: Say you have a whisper file with a 1 week and then 1month archive. If you write a point 1 day in the future, you're overwriting data from 7 days ago *and* from 30 days ago. While each of these archives will still be consistent when fetched (fetches only ever return data from a single archive - they dont get combined) this is quite unintuitive in my mind.

I do agree that the manipulation of from/until times as is can be quite confusing from a user perspective. I think though that any change to the existing behavior (and this would include the future case outlined in the original question) can be handled by the webapp. Currently the webapp requests the datestamp the user provides (via from= and until= parameters) but then renders only based on the time range of data it returns. It can instead use the requested datestamps for the graph width and render the requested data within that.

To answer the original question, there's a patch that was recently merged to the 0.9.x branch that will do what you need with timeshift:
http://graphite.readthedocs.org/en/0.9.x/functions.html#graphite.render.functions.timeShift

https://github.com/graphite-project/graphite-web/pull/12

If you want to stick with your 0.9.9 install it appears to apply cleanly except for the docstring:
 https://github.com/graphite-project/graphite-web/pull/12.patch

to handle arbitrary datapoints in the future, maybe we could extend retention policies to include the future, so the user could configure how far in the future he can store datapoints, and at which interval. however, let's not start implementing something like this until people actually start asking for it and explaining their use cases/problems.

oh and if, you want to store a datapoint in the future and it overwrites data from the past, that's a bug IMHO. whisper should either do as you say, or error.