Björn Rabenstein

With the [spec](https://prometheus.io/docs/specs/native_histograms/) being done and https://github.com/prometheus/prometheus/issues/13934 being done, I'm closing this. There are a few edge cases not yet implemented (see TODOs in the spec) but these do not...

To be clear: This is not about actual prediction. The title refers to the fact that Prometheus returns a potentially very problematic result when asked for a sample from the...

The Grafana problem has been solved by https://github.com/grafana/grafana/pull/16110 . I'll leave this issue open nevertheless. I think adding the maximum timestamp currently in the tsdb as suggested above is a...

> Those shouldn't be an issue, as it's either a compaction or a reload. I don't understand the relevance. If I add an overlapping block, I'll “change the past” and...

FYI: There was some troubleshooting happening behind the scenes. The outcome was that Prometheus behaves correctly and the graph shown in the previous comment only happens when Grafana and/or Thanos...

We just encountered this during the bug scrub. In very general, ever since Grafana changed its strategy, this doesn't seem to have bothered very many. We could simply close this....

Yeah, `@` with future timestamp can actually be a meaningful use case (if you craft some function that is actually meant to predict the future). From that perspective, it might...

About @jan--f 's other questions: > Is the time parameter still needed given that @ is stable? Yes. `time` is for the whole query, `@` is for a selector. They...

> The existing implementation by which `errors.Is(err, PromQLInfo)` is working seems a bit tricksy to me; better done via Go types. I guess this was my idea, seduced by the...

The [comment in lines 116 to 119](https://github.com/prometheus/prometheus/pull/14327/files#diff-d8edc673795ebafcce64036e85a031d0fd3d09cbcaea9bb1cc140373542afc92R116-R119) needs an update. (I cannot comment on unchanged lines directly, so I'm providing the link here.)