Inconsistent time aggregation parameters
location_event_counts has a count_interval API parameter to specify the length of time intervals to which the counts should be aggregated. This can take the value "day", "hour" or "min", and the result has columns date, (date, hour) or (date, hour, min), respectively.
total_network_objects has a total_by API parameter, which serves the same purpose. This can take any of the values "year", "month", "day", "hour", "minute" or "second", and the result always contains the column datetime.
The time aggregation in both of these queries (and any others that have an equivalent parameter) should be exposed in the same way. Other queries that perform temporal aggregation, such as unique_subscriber_counts (and all other aggregate queries that take start_date and end_date parameters) should also have an equivalent count_interval option (although we probably still want to allow the current behaviour - i.e. aggregate over the full time period from start_date to end_date).
We may want to consider some more flexible method for specifying temporal aggregation intervals. But whatever we decide, it should be consistent across query kinds.
This is becoming more important now FlowClient is being used more. Specifically the option to aggregate temporally is needed both for counting events and subscribers.
Options are currently "hour", "day" and "min" as @jc-harrison pointed out but ideally we'd add "week" and "month" too.
See also #3061. Obviously the work around in both cases is to do the slicing when creating the requests, but that's a pain in the bum.
The general case of this was on the roadmap if we got additional funding.