T09: Shifts and Time Schemes

Step 1 — See the problem#

Your daily measures currently run midnight to midnight, because that is the default.

Ask the plant when its day starts. In most manufacturing operations it is not midnight — it is the first shift start, typically 06:00. The production day that everyone discusses runs 06:00 to 06:00, and a night shift belongs to the day it started on.

Right now Infohub disagrees with the plant, and every daily total will be out by six hours' worth of production. That is not a rounding difference — it is a number that will not reconcile with the plant's own paperwork, ever.

Step 2 — Look at the seeded time scheme#

Your instance already has a time scheme called Production — --create seeds it.

Open it. The settings are a small set of offsets that together describe your calendar:

Step 3 — Move the day boundary#

Set the hour offset to 6.

That one change cascades:

• The day now runs 06:00 to 06:00
• The week starts at 06:00 on the day-offset weekday
• The month starts at 06:00 on its first day
• The year starts at 06:00 on the first day of the offset month

One setting, consistent all the way up the chain.

Recalculate a few days of Bottles Daily and compare against what it showed before. The values will differ — that is the six hours moving from one day to another.

Step 4 — Define the shifts#

Now add a shift scheme to the Production time scheme:

The night shift crosses midnight, which is normal and is exactly why shifts cannot be expressed as a simple offset — they need their own definition.

Step 5 — Why the offset had to be 6#

Look at how the two interact.

With hour offset 6, the production day begins with the Morning shift and closes with the Night shift. All three shifts belong to the same day, and the daily total equals the sum of its three shifts. A supervisor's numbers reconcile with the plant's.

With hour offset 0, the night shift would be split across two days — part before midnight, part after. Daily totals would not equal the sum of shifts, and no amount of explaining would make that acceptable to anyone.

Set the hour offset to your first shift start. That single rule prevents the most common calendar problem in Infohub.

Step 6 — Create shiftly measures#

The Shiftly interval is now available. Add to Filler 1:

Then a shift availability calculation:

Period.Duration.TotalMinutes == 0 ? 0
    : (Period.Duration.TotalMinutes - (Measure_<downtimeShiftlyId>.Value ?? 0))
      / Period.Duration.TotalMinutes * 100

Step 7 — Why Period.Duration matters here#

Your three shifts are eight hours each, so you could divide by 480 minutes.

Now suppose the plant changes to a pattern with unequal shifts — two twelve-hour production shifts and a two-hour maintenance window, which is a common arrangement:

A hard-coded 480 would be wrong on all three. Period.Duration.TotalMinutes asks each period how long it actually is and is correct in every case, with no special handling.

Totals do not have this problem — a sum is a sum regardless of shift length. Rates and percentages do, and they are exactly the measures people watch.

Step 8 — Crews are not shifts#

You may want to report by crew. Resist the urge to encode a rotating roster into the calendar.

The calendar describes time. Event schemes describe what was happening.

A four-crew, twelve-hour continental rotation is a roster, not a calendar. Trying to express it as time periods produces a scheme nobody can maintain, and it breaks the moment the roster changes.

The right shape: an event scheme for shifts with a Crew attribute, bound to an enumeration. You can then report by crew, compare crews, and change the roster without touching the calendar.

Step 9 — Financial years#

If your financial year does not start in January, set the month offset.

A July-to-June year uses an offset of July, and yearly measures, quarters, and year-to-date all follow automatically.

Where you need both calendars — operations on a calendar year, finance on a financial year — create a second time scheme and attach measures to whichever they belong to. This is the clearest legitimate use of multiple time schemes.

Step 10 — Understand the freeze point#

The freeze point marks everything before it as closed.

It does two jobs: it protects signed-off periods from being silently changed by a late value, and it stops the engine re-examining years of history on every pass.

Move it forward as periods are finalised — typically after month-end sign-off. Do not set it too close to the present, though: sources routinely deliver a little late, and a freeze point of "yesterday" discards legitimate data.

If old periods stop updating and the configuration looks correct, check the freeze point before anything else. It is doing exactly what it was told.

What you have learned#

Infohub's calendar is yours to define. Days, weeks, months, and years all follow from a handful of offsets.

Set the hour offset to your first shift start. Otherwise the night shift splits and daily totals will not equal the sum of shifts.

One offset cascades up the whole chain.

Shifts need their own definition, because they cross midnight and can be unequal.

Use Period.Duration for anything normalised by time. Hard-coded lengths break when the pattern changes.

Crews belong in event schemes, not calendars.

The freeze point protects history and saves work — and discards late data if set too aggressively.

Try this before moving on#

Compare a monthly average built two ways: aggregated from daily averages, and aggregated from hourly averages, for the same measure and month.

If they differ, you have partial days — and the two answers mean different things. The daily route weights every day equally regardless of how many hours ran; the hourly route weights every hour equally. Deciding which you actually want is a real modelling decision, and it is invisible until you look.

Next: T10: A KPI Dashboard — assembling everything so far into something people would use.

See also#

• T08: Measure Limits
• T10: A KPI Dashboard
• Interval Types and Time Schemes
• Shifts, Financial Years, and Custom Periods