Custom time ranges of N hours that span across a day boundary, i.e. midnight UTC, tend to fail.
It looks like the "from" timestamp for the API request is being calculated based on the day that the time range ends in, even though the UI is showing the day as being the previous day.
To replicate:
select a custom time range of last "N" hours, where N > the number of hours from now going back to the previous UTC midnight -- if now is 3am UTC, then N must be >= 4. If now is 9pm UTC, then N must be >= 22.
I suspect it is just some dodgy time arithmetic going on here that is not accounting for boundaries between larger time segments (hours arithmetic doesn't account for a change in day, etc.). This is why all time arithmetic should just use unix timestamps ;)
Custom time ranges of N hours that span across a day boundary, i.e. midnight UTC, tend to fail.
It looks like the "from" timestamp for the API request is being calculated based on the day that the time range ends in, even though the UI is showing the day as being the previous day.
To replicate: select a custom time range of last "N" hours, where N > the number of hours from now going back to the previous UTC midnight -- if now is 3am UTC, then N must be >= 4. If now is 9pm UTC, then N must be >= 22.
I suspect it is just some dodgy time arithmetic going on here that is not accounting for boundaries between larger time segments (hours arithmetic doesn't account for a change in day, etc.). This is why all time arithmetic should just use unix timestamps ;)