Methodology: how electricity interval data is interpreted and calculated

Interpreting intervals

Each row of a meter export describes one metering interval. The timestamp in the file may mark either the beginning or the end of that interval, and you tell the analyzer which convention the file uses.

• Start-stamped data: the timestamp is used directly as the interval start.
• End-stamped data: the timestamp is normalized backwards by the effective interval duration, so the record describes the interval it actually measures.
• The effective interval duration is the cadence in use for the analysis. When a file contains a sustained cadence change and you choose to analyze one detected segment, that segment's own cadence becomes the effective duration.

A kW value attached to an interval is the average demand across that interval. It is not an instantaneous measurement, and short peaks inside the interval are not visible in the data.

Demand and energy

Files supply either average demand in kW per interval or energy in kWh per interval. The analyzer converts between them using the interval duration.

Worked example: 60 kWh recorded during a 30-minute interval gives 60 ÷ 0.5 = 120 kW average interval demand. That figure is the average over those 30 minutes, not a peak instantaneous demand.

Summary metrics

Covered hours counts the intervals that exist in the data. It is deliberately not the elapsed wall-clock span between the first and last reading, so missing intervals do not silently inflate it.

Load factor is shown only when the implementation considers it meaningful; where it would not be, the analyzer shows no value rather than a misleading one. Worked example: a 40 kW average against a 100 kW maximum interval demand gives a load factor of 0.40, or 40%.

Peak-to-average ratio compares the maximum interval demand with the average demand over the covered intervals. It is shown only when average demand is above zero. It is a displayed ratio derived from the two metrics above rather than a separate calculation.

Percentiles and the load duration curve

95th and 99th percentile demand

The 95th percentile demand is the level that 95% of the analyzed intervals sit at or below; the 99th percentile is the equivalent level for 99% of intervals. They describe sustained high demand while being less sensitive to a single extreme interval than the maximum.

Load duration curve

The load duration curve sorts every analyzed interval by demand, from highest to lowest. Every interval counts equally: nothing beyond the interval observations themselves is duration-weighted, and each interval occupies an equal slice of the horizontal axis, with its point plotted at the middle of that slice. Reading across at a demand level shows the share of intervals at or above that level. The curve values themselves are the measured interval demands, with no interpolation or weighting applied.

Data quality

• Missing intervals are reported and never interpolated or filled in.
• Duplicate rows that agree with each other are removed and reported as identical duplicates.
• Duplicate rows for the same interval that disagree on the value are conflicting duplicates and block the analysis, because the analyzer cannot know which is correct.
• Timestamps that cannot be read are excluded and reported.
• Values that cannot be read are excluded and reported.
• Rows that carry only a date or only a time cannot be placed in time at all. These have their own blocking rule and stop the analysis until the column mapping is corrected.
• Negative readings are kept in the analysis and flagged, since they can be legitimate (for example export) or a data problem.

Technical note: analysis is blocked when more than 5% of all data rows contain unusable timestamps or unusable values, because that usually indicates a mapping or source-data problem. The timestamp share counts unparseable timestamps plus non-existent local times, measured against all data rows in the file; rows with only a date or only a time are not part of that percentage and block through their own rule. The value share counts unparseable values against all data rows. Exactly 5.0% does not trigger the rule — the threshold is strictly above 5% — and a file in which every row fails has its own separate blocking message. This threshold is fixed behaviour, not a setting.

Timezones and daylight saving time

Local timestamps that carry no offset are resolved in the meter or site timezone you select, so the same file analyzed in a different timezone can describe different instants. Timestamps that contain an explicit UTC offset already identify a real instant and are used as such, regardless of the machine running the analysis.

When clocks go forward, some local times never occur. Rows with such a non-existent local time are excluded and reported rather than shifted into a neighbouring interval.

When clocks go back, the repeated local hour appears twice. The analyzer resolves it automatically only when the file contains a complete, evenly spaced double pass through that hour, where a single assignment is the only one consistent with the reading interval. In every other case it stops and asks you to decide for that hour — keep the first pass, keep the second, or exclude those readings. Ambiguous local times are never guessed.

Reading interval and cadence changes

Supported reading intervals are 5, 10, 15, 30 and 60 minutes. The analyzer detects the cadence from the data where it can, and you can override the detected value.

Where a file changes cadence for a sustained stretch — for example 15-minute readings followed by 30-minute readings — analyzing the whole file as one series would misstate energy and coverage, so whole-file analysis is blocked. The analyzer reports the detected segments and you can analyze one of them. The selected segment's cadence then becomes the effective interval duration for every calculation on that segment.

At the boundary between two cadence regimes, each reading belongs to exactly one segment. In start-stamped data the boundary reading belongs to the following regime; in end-stamped data it belongs to the preceding regime, because that is the interval the timestamp actually describes.

Additional-load scenarios

An additional-load scenario adds a constant load in kW during a schedule you define: selected weekdays and a local time window, which may run overnight past midnight. The added load is applied only to intervals that exist in the meter data; missing intervals are never filled in to complete a schedule.

The energy added to an interval is based on the real elapsed overlap between that interval and the schedule window, so a partial overlap adds a proportional amount. Because the overlap is measured in real elapsed time, a window that spans a daylight saving transition correctly accounts for the hour that is added or removed.

Worked example: 15 kW added for 15 minutes of a 30-minute interval adds 15 × 0.25 = 3.75 kWh to that interval.

The scenario also reports how many hours the schedule requested, how many of those hours actually have meter data behind them, and the resulting coverage. Low coverage means the scenario result describes only the part of the schedule your data covers. These are arithmetic what-if figures, not an electrical-network or load-flow simulation.

Peak-limit analysis

Peak-limit analysis compares a demand limit you choose with the interval-average demand of the data being analyzed — the observed data, or the active additional-load scenario when one is applied. Nothing is shifted, reduced or optimized: the analyzer only reports what the measured sequence would mean against that limit.

Every interval above the limit is counted. Consecutive exceeding intervals are grouped into one exceedance event. The affected days, the largest overshoot, the energy above the limit and the longest event are all derived from that observed interval sequence.

Worked example: one 30-minute interval at 120 kW against a 100 kW limit is an overshoot of 20 kW, so the energy above the limit is 20 × 0.5 = 10 kWh.

Normalized export

The CSV export contains the analyzer's normalized interval records — the data exactly as it was interpreted, after mapping, timezone resolution and duplicate handling. Each row carries:

• the source row number from your file
• the normalized local interval start and end
• the UTC offset in minutes that applied at that instant
• the effective interval length in minutes
• the interval energy in kWh
• the average interval demand in kW
• how the timestamp was resolved, including any daylight saving resolution

The export is generated in your browser from the analysis already on screen.

Interpretation limits

• Interval demand is average demand over the interval, not instantaneous demand, so peaks shorter than one interval cannot be seen.
• Missing data stays missing; nothing is estimated to fill a gap.
• Every figure reflects the file you supply, so results are only as accurate and complete as that data.
• Scenario outputs are arithmetic what-if calculations applied to observed intervals only.
• There is no electrical-network or load-flow modelling, and no forecasting.
• There is no electricity pricing, tariff comparison or bill estimation of any kind.
• The timezone you select changes how local timestamps resolve, and therefore the results.
• Files with a sustained cadence change require choosing a segment to analyze.
• Regression testing includes a 100,000-row, 5-minute dataset; actual browser performance depends on the device.