Description
Whilst wrestling with another issue I discovered that data returned by the feed/data.json api can be somewhat misleading as the returned datapoints are often non-existent as the returned data uses the requested search ref timestamp derived from the start, stop and interval times, not the timestamps of the located datapoints.
See https://community.openenergymonitor.org/t/unearthed-a-quirk-with-editrealtimedata-timestamps/8378/4?u=pb66 to see how this adversely affects the editrealtime vis (lol - I just just realised how unfortunate that name choice is when there are no "real times" being used at all).
I understand different characteristics maybe desirable for other applications and backwards compatibility is of course a priority, so perhaps we could have a "truetimestamp" option? where the "found" timestamps are returned rather than the calculated search intervals.
Also, in conjunction with the above a "reverse direction only" option (catchy name I know :-) ) so that the "reading" of fixed interval feeds is the exact inverse of "writing" to them ie the nearest whole interval eg searching for 1535709539 will return 1535709530 not 1535709540. Again this should be an option arg rather than a system wide change. This is necessary for the editrealtime too, as it is possible to read one data point and save the edits to a neighboring data point as read effectively uses round but write uses floor behavior.
also see #1006, the above issues specifically with editrealtime is reported as a bug. Where as this is a request for enhanced feed api functionality, independent of that bug, but I do believe these options would remidy #1006