I am trying to understand how the periodic aggregation for a tag history binding works.
More specifically the behavior of the time units in the dropdown:
DAY seems correspond to sliding 24h (based on selected time) and not from 12am to 12am, right?
Same question goes for WEEK (sliding 7 days?) and MONTH (sliding XX days?).
For a historical binding, if you set the query mode to periodic, the end date of the query will be adjusted to give you an even N intervals of size period from start to end. So if you want e.g. midnight -> midnight intervals, you just make sure that your start date is normalized to midnight before passing.
To be clear, could you therefore please confirm the following behavior:
1 DAY = 24 HOURs
1 WEEK = 7 DAYs = 168 HOURs
1 MONTH = 28? 30? 31? DAYs
IMHO I don't see the point of these units if this is the case. It is prone to confusion.
Also I don't quite understand the adjustment you mention. Want happens if the diff between end and start is not a multiple of the period? Let's say the diff is 40 hours and the period set is 24 HOURs. Is the period resized to 20 hours for even intervals or else?
I mean, would you rather set a period of 604800 seconds, or 1 week? It's all ultimately milliseconds under the hood. The different units are just a convenience.
From what I see in the code, it looks like in this particular case the end date would be adjusted to 48 hours (i.e. start: Jan1@midnight, end: Jan3@midnight) but the 'return size' will be 2, so you'll get two output rows: Jan1@midnight, and Jan2@midnight.
In other words: The window is always enlarged to fit the interval specified.
Yeah, it's admittedly imperfect. For what it's worth, a month is hardcoded to 30 days, and a year is hardcoded to 365 days. True date math would definitely be nice to have in these functions, but will probably have to wait for a larger revamp of the historian down the road.
My point was more on the semantic.
but what about month (and year to a greater extent)?