mactyr

In case anyone else is here because you're seeing date shifts by 1 hour that might be related to daylight savings time changes somehow having an effect on the value...

I believe the problem is related to daylight savings time changes, in the machine's local timezone, even though that shouldn't affect UTC dates. Here's my setup, using excel4node 1.7.2: ```...

When I change line 143 (and line 150, which is identical) to the following, to add exactly 24 hours rather than "1 date" to `thisDt`, it seems to fix the...

I had an idea on this that I ran by Artem on a call a few weeks ago; he seemed open to it and I'd like to propose it here....

@valyala, the time has come when we have some isolated bad data points in our production db that should be deleted, so I'm returning to try to rally some interest...

Thank you! I have built from source and confirmed that `-search.maxPointsPerTimeseries` and `-search.maxPointsSubqueryPerTimeseries` now work as requested. One minor suggestion: I notice that when I exceed either of these limits,...

Aha, thanks @zekker6, I agree that adding `1i` as the window modifier fixes the problem! A few follow-up questions: 1. I had expected the window modifier to default to `1i`...

Thanks @hagen1778, I am working on using workaround number 2 in my application (explicitly specifying the step of the subquery to be small enough that alignment to UTC isn't an...

@valyala, if I understand correctly, `increase_prometheus` _would_ solve the gap-before-the-first-interval problem I described above, but it would also have the downside of Prometheus' approach, [as you describe](https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e); that is, it...

@hagen1778, @valyala, is it possible that VictoriaMetrics could tackle this as a way to sidestep the problem described in #6437? It would significantly improve the accuracy of the data we...