clock
A public forecasting record for European power. Every day a forecast, the next day the score, every file timestamped and never edited.
0 of 30 delivery days scored against the operator's own forecast.
The headline number, DE-LU wind day-ahead against the TSO's forecast, is withheld until 30 days are on record. A score over a handful of days measures nothing and looks like it does.
Day-ahead, all targets
| Zone · target | Days | Metric | Clock | Persistence | Weekly | Operator | Skill vs operator |
|---|---|---|---|---|---|---|---|
| DE-LU · wind | 0 | nMAE | · | · | · | · | · |
| DE-LU · solar | 0 | nMAE | · | · | · | · | · |
| DE-LU · load | 0 | MAPE | · | · | · | · | · |
| DE-LU · price | 0 | MAE | · | · | · | none exists | · |
| ES · wind | 0 | nMAE | · | · | · | · | · |
| ES · solar | 0 | nMAE | · | · | · | · | · |
Day-ahead (lead 1), mean of daily scores, every source over the same hours. Solar over daylight hours only. Operator columns count only days where the TSO forecast was captured before delivery.
By lead time
| Lead, days | Days | Clock | Persistence | Weekly |
|---|---|---|---|---|
| 1 | 0 | · | · | · |
| 2 | 0 | · | · | · |
| 3 | 0 | · | · | · |
| 4 | 0 | · | · | · |
| 5 | 0 | · | · | · |
| 6 | 0 | · | · | · |
| 7 | 0 | · | · | · |
DE-LU wind, nMAE, % of installed capacity. Leads 2 to 7 have no official forecast to compare against; they are on record so that the series exists when they do.
Intraday
Nothing scored yet.
Latest issue
Issued 2026-09-12T05:28:41Z, before the day-ahead gate closure (2026-09-12T10:00:00Z), for delivery day 2026-09-13 and six days beyond. Model naive-v1.
data/forecasts/2026-09-12.json · proof
1 issue days since 2026-09-12, no gaps.
Method
Every day at about 07:40 UTC, before the day-ahead market closes at 12:00 CET, a scheduled job downloads the latest actuals from the ENTSO-E transparency platform, writes a forecast for every hour of the next seven delivery days, commits it to the public repository and anchors its hash in the Bitcoin blockchain with OpenTimestamps. The next day it downloads what happened, scores every source over the same hours, and publishes the score next to the forecast. Seven days later it scores again with the revised actuals, in a second file; nothing is overwritten.
The operator's own day-ahead forecast is polled through the day and stored with the time it was first seen complete, because the regulation sets a deadline for publishing it, not a time, and a comparison against a number of unknown availability is not a comparison.
Zones: DE-LU and ES. Targets: wind, solar, load and day-ahead price for DE-LU; wind and solar for ES. Price has no official forecast and is a dated series only. Phase 1 model naive-v1 is deliberately naive (wind: persistence, solar: mean3, load: weekly, price: weekly); persistence and weekly baselines are always published beside it. The scarce thing is the dated series, and the method improves forward.
Wind and solar are scored as nMAE, a share of installed capacity; solar over daylight hours only. Load as MAPE. Everything is hourly means of the platform's quarter-hour values, in UTC; delivery days follow the CET/CEST calendar and have 23, 24 or 25 hours when the clocks change.
Verify
Every file under data/ has a .ots proof beside it. To check that a forecast existed before the day it forecast:
pip install opentimestamps-client ots verify data/forecasts/2026-09-12.json.ots
Or drop the file and its proof at opentimestamps.org. A fresh proof says pending until its Bitcoin block is mined, typically within a day; the job upgrades proofs as blocks arrive. The commit history is a second, independent witness. The full record and code are at https://github.com/carlo-coding/clock.