Time range rounding seems wrong when looking small intervals

[lukester1975]

Hi

Very small time period can miss data points, due to the data source rounding up the from time in getPrometheusTime(). E.g. for a range requested as from=2025-04-14T17:41:49.517Z&to=2025-04-14T17:41:50.503Z can look like:

Using the prometheus data source doesn't exhibit the same behaviour, though I haven't looked in to why (not sure if it sends sub-second timestamps, or rounds differently).

Anyway, a trivial fix still using seconds is to use ceil/floor as appropriate:

  getPrometheusTime(date: string | DateTime, roundUp: boolean) {
    if (typeof date === 'string') {
      date = dateMath.parse(date, roundUp)!;
    }

    if (roundUp) {
      return Math.ceil(date.valueOf() / 1000);
    } else {
      return Math.floor(date.valueOf() / 1000);
    }
  }

Which looks better:

Happy to make a PR but I've no idea if this is the best approach. It was just an obviously quick workaround once I realised where the rounding was happening.

Thanks!

[Loori-R]

Example

• From: 1696284014000 (2023-10-03 00:00:14) - same for both.
• Step: 15s (auto).
• First point in Prometheus: 1696284000000 (00:00:00).
• First point in VictoriaMetrics: 1696284014000 (00:00:14).

Why
Prometheus query_range snaps timestamps to the step grid and takes the first point at the nearest multiple ≤ start. VictoriaMetrics returns points strictly from the provided from without snapping. VMUI behaves the same as our current VM datasource.

Question
@arturminchukov, @dmitryk-dk, Should we change to Prometheus-style snapping, or keep the current behavior?

[arturminchukov]

Question @arturminchukov, @dmitryk-dk, Should we change to Prometheus-style snapping, or keep the current behavior?

For me more logically looks the prometheus graph, so IMO will be better to change to Prometheus-style snapping. Cause the VM graph looks like there no data.