Proposal

It would be very helpful to be able to use the timestamp from @ start() and @ end() as a scalar anywhere that a float literal is permitted, such as:

• in scalar arithmetic expressions for things like computing values per-second of the wall-clock range covered by the query ( rate() and deriv() compute it over the range-vector's time range, which may differ from the time-range of the query as a whole);
• in arithmetic in range and subquery selectors including the min() and max() introduced along with the experimental new step() function, to compute ranges like foo[(end()-start())+step():step()] to produce a subquery that targets values wholly within the outer range query's span, without the first step capturing values older than the start of the range query's span

It's possible to somewhat work around the current limitation with expressions like timestamp(last_over_time(up{}[5m]) @ end()) - but the timestamp reported will be the timestamp of the last sample in the range, which may be several seconds before the true end-of-range depending on the sample interval. It's also more difficult for the start timestamp due to the lack of a first_over_time(...) function.

There's precedent for this in the new step() pseudo-function, which is accepted in range expressions though not yet in place of a literal:

$ promexec 'step()'
query error: bad_data: invalid parameter "query": 1:5: parse error: unknown node type: *parser.DurationExpr
command terminated with exit code 1

Related

• Support start(), end() and new step() function in subqueries #16964

References

• Functions for range and subquery range_start_ts(), range_end_ts(), range_span_seconds(), range_step_seconds() #16962
• @end() and @stat() for instant query do not behave as per the documentation #15838
• Add step(), min() and max() in promql duration expressions #16777
• PromQL makes it unnecessarily inefficient to work with time series timestamps even in straightforward cases #8966
• Support start(), end() and new step() function in subqueries #16964