How to make Home Assistant electricity schedules safe across DST

Abstract

Home Assistant schedules can fail at daylight-saving-time boundaries when a local clock label is mistaken for a unique delivery interval. The failure is structural: the spring transition has a shorter local day, while the autumn transition repeats part of the displayed clock. This working paper examines a clock-safe alternative using the frozen Volt home-energy evidence snapshot. The analysis counted 16 zone-days whose price-interval durations summed to 23 or 25 hours. The evidence artifact reports 16 zone-days, an aggregate sample size of one, and no uncertainty interval for this estimand. This is a descriptive integrity result, not a measurement of household devices or Home Assistant installations.

The central design is to identify actions by the UTC delivery start and end carried by the market interval, retain the market’s native interval duration, and use the local date only for presentation and local-day completeness checks. A controller should reject a schedule if UTC intervals overlap, repeat, leave an unexplained gap, target the wrong local delivery day, or fail the weighted-duration check. It should never manufacture an ordinary 24-hour day at a clock transition. The observed inputs came from a SELECT-only production snapshot, but the “interval fixture” is an analytical reconstruction of those inputs; it is not a production execution receipt and not a claim that a repository integration test was run. The practical conclusion is therefore narrow: UTC identities plus explicit local-time rendering provide a defensible basis for DST-safe automation, provided the adapter fails closed whenever that identity cannot be verified.

Plain-language answer

Do not tell Home Assistant merely to act “at 02:30 tomorrow.” On the spring clock-change day, that displayed time may not exist. On the autumn clock-change day, it may occur twice. Instead, obtain the complete market curve, keep each interval’s UTC start, UTC end, and duration, and schedule against those UTC values. Show the user a local time and timezone, but do not use the display label as the command’s unique key.

The frozen evidence found 16 delivery days with a total duration of either 23 or 25 hours in the analyzed interval reconstruction. Those are valid market days, not automatically missing-data incidents. A safe integration should accept a short or long local day only when the UTC intervals remain contiguous and their durations add to the expected local-day length. If the payload instead contains a duplicate UTC start, an overlap, a gap, a changed timezone, or an incomplete target day, the automation should withhold new device commands and move to a declared safe fallback. A fallback might preserve an already validated comfort schedule or stop optional charging; which response is safe depends on the appliance, and this paper does not prescribe device-specific safety behavior.

Research question

The research question is: what data identity and validation rules are sufficient to make a Home Assistant electricity schedule robust to daylight-saving-time transitions without hiding incomplete market data?

The question separates three concepts that are often collapsed. A delivery interval is an absolute period with a beginning and end. A local clock label is a human-readable representation of an instant in a named timezone. A local delivery day is a market grouping whose elapsed duration can differ from 24 hours. A robust adapter must preserve all three without letting one substitute for another.

The paper does not ask whether a particular Home Assistant automation, operating system, device firmware, or household network behaves correctly. No customer installation was exercised. It also does not estimate savings. The measured object is the presence of DST-length delivery days in the frozen interval reconstruction and the integrity implications of that fact. The decision criterion is fail-closed: can an adapter prove that every scheduled command maps to exactly one intended UTC interval on the intended local day? If not, it should not emit a new price-driven command.

Data and provenance

The public evidence file is the machine-readable authority for the numerical result. It identifies this paper as VOLT-HOME-WP-091, labels the status measured, and binds the output to the volt-home-paper-evidence-v1 schema. The publication cutoff is 2026-08-30T00:00:00Z. Its shared data windows are 2021-01-01 through 2026-08-29 for daily prices, 2025-10-01 through 2026-08-29 for detailed intervals, and 2015-01-01 through 2026-08-29 for long history. This analysis uses the detailed interval reconstruction; the broader windows describe the common corpus and must not be misread as the span of every metric.

The source contract names auction_publications, grid_revisions, ingestion_runs, public API schemas, and repository integration fixtures. The actual DST count was derived from price-day interval groups in the frozen analytical snapshot. That snapshot was extracted from production in a read-only transaction with a 180-second statement timeout. Its SHA-256 is 7e97489fc8528c8cc8c38830e05b48d949ce1f67b98575dff26f5d7c321e4c67; the analysis-code hash is 57c57de79cdab2b5b6d6c54c485cb5162598c5ba0b0bfe995da40d75e6c52ba9; the protocol hash is adb36bf6b447af9f96339249b8becaefc20422499cca1977242866347a97bd4b; the paper-registry hash is 7bcb91d7476d0a69fe9fa75a5c7782f8117e0153f82f9112b7e1d307d3943717; and the source-registry hash is 07949550ac443ff673fda5c0209b99f137544f3ffecf6775f109bb9d09663bd6. The evidence-manifest hashes are 68ac127d16e4eca54c1d7ee8e70b782a7f78a47f36cd134264f507170e79077a for the JSON and 365bd00361907bb0698396a89abe19a376de20ae26a18ae4daacf1e2a688227b for the WebP figure.

This provenance distinction matters. Production-origin price rows are observational receipts of stored market intervals. Grouping them into an “interval fixture” is deterministic analysis. It is not a receipt from Home Assistant, not an execution log from a charger or heat pump, and not evidence that any repository contract-test suite passed. The public aggregate contains no raw licensed payloads. Licensing details are delegated to the project licensing notice.

Method

The analysis grouped native price rows by zone and local delivery date. For each group, it summed the elapsed duration represented by each interval. A group was classified as a DST-length day when that weighted duration equalled 23 or 25 hours. The outcome was the count of qualifying zone-days. The code then wrote the paper-level aggregate and a deterministic figure. The public artifact reports an aggregate sample size of one, bootstrap_95_interval: null, and interval_method: "not reported for this estimand". Deterministic reproduction of the count does not quantify population uncertainty.

The integration method implied by this measurement has four boundaries. First, normalize every source timestamp to an offset-aware instant and retain the original timezone context needed for display. Second, key commands by immutable delivery identity: zone, UTC start, UTC end, and a version or revision identity where relevant. Third, validate the complete target local day by sorting UTC intervals, rejecting overlaps or gaps, and summing durations rather than counting rows. Fourth, translate to Home Assistant only after validation, with local labels carrying an explicit UTC offset so the repeated autumn hour remains distinguishable.

There is a real design tradeoff. Scheduling entirely in local wall time is readable but ambiguous. Scheduling entirely in UTC is unique but can obscure which local day the user intended. Expanding every day to a synthetic 24-hour template is superficially uniform but corrupts clock-transition days. The selected design keeps UTC as the execution identity and local time as a verified view. That adds adapter complexity, but the complexity is explicit and testable rather than hidden in daylight-saving behavior.

Results

The primary result is 16 DST-length zone-days in the interval reconstruction. The metric unit is zone-days. The evidence records an aggregate sample size of one, a value of 16, and no interval estimate. The figure has one item, “23/25-hour fixtures,” with the exact value 16. The predefined interpretation is that UTC identities plus local display dates avoid duplicate or missing Home Assistant actions.

This count demonstrates that non-24-hour local delivery days are present in the frozen corpus and therefore cannot be treated as hypothetical edge cases. It does not show how frequently an individual household encounters the transition, because the unit spans zones and days. It does not show an error rate for Home Assistant. It also does not prove that every 23- or 25-hour group is complete merely because its duration is correct; continuity and uniqueness checks remain necessary.

The result supports a data-contract conclusion, not a product-performance claim. Any downstream system that silently assumes a fixed number of intervals per local day can misclassify valid data or schedule the wrong occurrence of a repeated time. A duration-aware system can represent the day correctly, but only if it preserves the source timestamps and refuses ambiguous conversions.

Robustness and placebo checks

The primary robustness check is internal consistency across three views: sorted UTC continuity, explicit interval duration, and the expected weighted duration of the named local day. A valid transition day should pass all three. Row count alone is intentionally not sufficient, because native market resolution can differ and a valid day can contain a different number of rows without losing elapsed time.

Useful deterministic fault-injection checks for an integration include deleting one interval, duplicating a UTC start, swapping two boundaries, stripping the timezone offset, and coercing a 23- or 25-hour day into 24 hours. These are proposed acceptance checks, not tests claimed as measured by this paper. Each should produce a rejected schedule rather than a best-effort command stream. A placebo ordinary day can verify that the same validator accepts a contiguous day with its expected duration; that placebo tests over-rejection, not DST correctness by itself.

The evidence family is descriptive and makes no unadjusted significance claim. Its multiplicity note says within-family Holm control applies to inferential claims, but no inferential comparison is promoted here. The strongest reproducibility check available from the artifact is hash-bound rerunning of the same frozen snapshot and code. The absence of a reported interval should not be presented as proof that the underlying phenomenon has no uncertainty.

Limitations

The principal limitation is scope. Production-origin market rows do not measure a customer’s Home Assistant scheduler, local network, host clock, operating system timezone database, charger, heat pump, or firmware. The analysis therefore cannot estimate device failures or certify a specific integration.

The aggregate sample representation also limits statistical interpretation. The result is stored as one aggregate count, and the evidence reports no interval. Zone composition and the detailed distribution between 23- and 25-hour days are not exposed in the paper-level JSON. No causal claim follows from the count.

Timezone rules can change, and an adapter may use a timezone database that differs from the environment used to create the schedule. A correct UTC curve can still be displayed incorrectly if the timezone identifier is missing or stale. Device APIs may accept only local times, forcing the adapter to carry an explicit fold or offset through an additional translation layer. Those paths require device-specific verification beyond this corpus.

Finally, this result does not establish retail savings, comfort, emissions, or trading performance. It is not trading advice. It says only that a schedule must preserve delivery identity at clock transitions and should fail closed when it cannot.

Practical implication

A Home Assistant integration should treat a price schedule as an immutable set of delivery intervals, not as a list of hour labels. Before publishing entities or firing services, it should verify the requested zone, target local date, UTC ordering, non-overlap, contiguity, duration, native resolution, source/revision identity, and freshness. The resulting command key should include the UTC delivery start, device or automation identity, and source revision so a retry cannot accidentally address the other occurrence of a repeated local time.

For user presentation, display the local timezone and UTC offset beside each transition-hour action. For execution, arm only commands derived from the last fully validated curve. If a refreshed curve fails validation, keep it quarantined and expose an explicit unavailable or stale state. Do not fill a missing spring interval, delete one autumn interval, or infer an offset from the host machine’s locale.

Fail-closed behavior should be appliance-aware. Optional EV charging can usually be withheld pending a valid schedule; essential heating may require a conservative thermostat fallback rather than shutdown. The adapter should declare that fallback in configuration and logs. This paper offers the integration invariant—no new price-driven action from an ambiguous interval—but leaves the safety policy to the device domain.

Reproducibility

The public reproduction package consists of the evidence JSON, the figure, the preregistered corpus protocol, the paper registry, the source registry, and the analysis code identified by their hashes. A reproduction should verify the paper ID, slug, title, status, evidence path, figure path, source IDs, publication cutoff, all five provenance hashes, and both evidence-manifest artifact hashes before reading the result.

Using the same frozen snapshot, group interval rows by zone and local date, sum each row’s elapsed minutes, convert to hours, count groups equal to 23 or 25, and confirm the output is 16. Also confirm that no writes occur: the provenance records a read-only transaction and a 180-second statement timeout. A different data vintage is a replication, not a reproduction, and should publish a new cutoff and hashes rather than overwrite this result.

For integration verification, maintain separate labels for observed production-origin records and deterministic fault-injection fixtures. A future report should state exactly which adapter version, timezone database, Home Assistant version, device API, fixtures, and production receipts were tested. This paper does not supply those measurements and must not be cited as though it did.

Disclosure

Analysis and drafting were model-assisted. The paper is a public working paper. It is not peer reviewed and makes no claim of academic publication. Sources, assumptions, code and evidence hashes are disclosed through the registry and evidence artifact. Voltcast is the publisher of the internal architecture source and the producer of the analyzed aggregate.

No customer data, support content, restricted order-book evidence, live-trader evidence, or live-capital result is used. Volt has no live traders or live capital; C0R is the only paper strategy, and production weather forecasting is a non-trading service. This paper is not trading advice, device-safety certification, or a promise of savings.

References

1. Google Search Central, Article structured data.
2. Google Search Central, Introduction to structured data markup in Google Search.
3. Google Search Central, Spam Policies for Google Web Search — Scaled content abuse.
4. ENTSO-E, Single Day-ahead Coupling (SDAC).
5. Voltcast, Voltcast Architecture.