Tag history binding periodic aggregation


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?).

I looked at the Tag History Bindings in Perspective documentation but there is no precision on this matter.

I'd be grateful if someone could shed some light on this subject.


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.

Ok, thanks, this confirms my observations.

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.

1 Like

Haha, sure :sweat_smile: My point was more on the semantic.

I agree a week is 604800 seconds :upside_down_face: but what about month (and year to a greater extent)?

Understood! Thanks for looking into the code!

I think all this deserves to be documented.

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.

1 Like

Thanks for clarifying month and year.

For me, the main point is properly understanding the implemented mechanics to avoid surprises.