Interval Types and Time Schemes
Infohub does not assume a day starts at midnight. A time scheme is where you tell it when your periods begin.
Most reporting tools assume a day runs midnight to midnight and a month is a calendar month. Plants do not work that way. A production day might start at 06:00, a week on Monday, a financial year in July. Infohub handles this with the time scheme — a definition of when your periods begin, which every aggregation then respects.
The interval types#
Infohub has nine intervals. A measure sits at exactly one.
| Interval | Shown as | Notes |
|---|---|---|
| Timestamp | Tag | Not an interval — raw values at source timestamps |
| Minutely | Minute(s) | Granularity set by the time scheme |
| Hourly | Hour(s) | |
| Shiftly | Shift(s) | Boundaries come from the shift scheme |
| Daily | Day(s) | |
| Weekly | Week(s) | |
| Monthly | Month(s) | |
| Quarterly | Quarter(s) | |
| Yearly | Year(s) |
Tag is the odd one out and worth restating: it has no interval, interval charts refuse it, and you cannot aggregate from it directly to Daily. Derive an Hourly or Minutely measure first.
What a time scheme defines#
A time scheme is a small set of offsets that together describe your calendar.
| Setting | What it controls | Example |
|---|---|---|
| Minute interval | The granularity of a minutely period | 1, 5, 15 minutes |
| Minute offset | Minutes past the hour an hour begins | 00, or 30 for half-past-to-half-past |
| Hour offset | The hour a day begins | 6 for an 06:00 production day |
| Day offset | The weekday a week begins | Monday |
| Month offset | The month a year begins | July for a July–June financial year |
| Manual | Whether Infohub generates the periods or they are managed externally | Automatic is recommended |
| Freeze | The point before which periods are closed to recalculation | See below |
| Label | How periods are labelled |
Those five offsets cascade. An hour offset of 6 makes the day run 06:00 to 06:00; the week then runs from 06:00 on the day-offset weekday; the month from 06:00 on its first day; the year from 06:00 on the first day of the offset month. One setting, consistent all the way up.
This is why you aggregate in Infohub, not in the historian. A historian will give you daily values, but its day starts at midnight and it has never heard of your 06:00 shift change. Retrieve raw values and let Infohub's time scheme define the periods — that is the whole point of the aggregation chain.
Multiple time schemes#
You can define more than one, and measures are attached to the time schemes they belong to. That matters when one plant reports on more than one calendar:
- Operations on an 06:00 production day, and Finance on a midnight calendar day
- A financial year starting in July alongside a calendar year
- Two production areas on genuinely different shift patterns
A new instance is seeded with a time scheme called Production. If your calendar is going to be called Production, use the seeded one rather than creating a second with the same name.
Do not solve everything with more calendars. Every additional time scheme multiplies the periods the engine generates and the measures attached to them. Two or three well-chosen schemes are normal. A dozen usually means the model is compensating for something that belongs in shifts or event schemes instead.
The freeze point#
The freeze point is the date before which periods are considered closed.
Its purpose is protection and performance. Once a month has been reported and signed off, you generally do not want a late-arriving value silently changing it, and you do not want the engine re-examining years of history at every scan. Setting the freeze point tells Infohub that everything before it is settled.
Practical guidance:
- Move it forward as periods are finalised, typically after month-end sign-off.
- Do not set it too close to the present. Sources routinely deliver values a little late, and a freeze point of "yesterday" will discard them.
- If you need to correct frozen history, move the freeze point back, recalculate the range, then move it forward again.
A freeze point that is too aggressive looks like missing data. If values stop arriving for older periods and the configuration looks correct, check the freeze point before anything else. It is doing exactly what it was told to.
Time zones#
Periods are stored in UTC and converted for display. Expressions see both: Period.Start and Period.End are UTC, Period.StartLocal and Period.EndLocal are converted.
The practical rule: use the Local properties whenever you compare against a wall-clock time a person would recognise. Comparing Period.Start.Hour against a shift start time is a classic bug that works in winter and breaks when the clocks change, or works on a UTC server and breaks on a local one.
Daylight saving makes some days twenty-three or twenty-five hours long. This is why Period.Duration.TotalHours is better than assuming 24 in any calculation that normalises by period length.
Choosing intervals for a model#
Hourly is the workhorse. It is fine enough for operational reporting, coarse enough to keep the model manageable, and it is the natural base for daily, weekly, and monthly.
Minutely only where you need it. A minutely measure produces sixty times the values of an hourly one, and everything above it inherits that volume. Use it for peak demand, short-cycle equipment, or fast process control analysis — not by default.
Shiftly where shifts drive accountability. If supervisors are measured per shift, the shift interval is what makes reports match how the plant is actually run.
Weekly, quarterly, and yearly on demand. Add them when someone asks. Building the full chain to yearly for every tag creates a very large model that nobody looks at.
Diagnosing period problems#
| Symptom | Usual cause |
|---|---|
| Daily totals do not match the plant's own daily numbers | Hour offset wrong — Infohub's day boundary differs from the plant's |
| A day appears to have 23 or 25 hours | Daylight saving; correct behaviour |
| Weeks start on the wrong day | Day offset |
| Financial year is out by six months | Month offset |
| No new periods being generated | Time scheme set to Manual, or the engine that builds it is not running |
| Late values ignored | Freeze point too recent |
| Shift boundaries wrong | Shift scheme rather than time scheme — see Shifts, Financial Years, and Custom Periods |
Changing a time scheme on a live model#
Changing an offset changes what every period means, for every measure attached to that scheme. A day that ran 06:00–06:00 and now runs 00:00–00:00 covers different data, so historical values no longer describe the periods they are stored against.
Treat it as a significant change:
- Understand which measures are affected — everything attached to that scheme.
- Decide what happens to history. Usually it must be recalculated, and that requires the freeze point moved back.
- Do it in a maintenance window, not during a reporting period.
- Warn whoever consumes the reports, because the numbers will move.
If only part of the model needs a different calendar, a second time scheme is safer than changing the existing one.