Template the per-reference-year timeslice window patterns

[nick-gorman]

AEMO's PLEXOS data package ships a timeslice calendar (timeslice_RefYear5000.csv): one row per on/off event recording, on absolute dates across the whole model horizon, when each region's demand-condition timeslice — peak (hot day), typical-summer, or winter — switches on (-1) or off (0). The dates aren't arbitrary: AEMO assigns each planning financial year a reference (weather) year from a rolling 16-year sequence (Table 1 of the Draft 2026 ISP Market Model Instructions) and lays that year's conditions onto the calendar. So a given weather year recurs every 16 years, and the calendar is really one annual pattern per reference year, stamped repeatedly across the horizon.

This PR adds the templater step that inverts that into one month-day window pattern per reference year. It pairs each on-event with its following off to form a window, labels the window by the financial year it starts in (and so by that year's reference year), checks every occurrence of a reference year carries the same pattern, and keeps one. The translator (a later PR) re-sequences these patterns onto the user's configured reference_year_cycle.

timeslice_RefYear5000.csv  (FY2026 maps to reference year 2015):
  DATETIME     NAME         TIMESLICE
  18/11/2025   NSW Hot Day  -1          # peak on
  20/11/2025   NSW Hot Day   0          # peak off
  01/04/2026   NSW Winter   -1          # winter on
  01/11/2026   NSW Winter    0          # winter off

timeslices  (templated, abridged — a real reference year has several peak/summer windows):
  timeslice_id          reference_year  start_month_day  end_month_day
  nsw_peak_demand       2015            11-18            11-20          # end exclusive
  nsw_winter_reference  2015            04-01            11-01          # spans 1 July

The decode stays this simple — pair an on with its own off, label by start year — because of how AEMO's data is shaped. Within a reference year the windows tile the year exactly, with peak and summer carrying the weather variation; winter is a fixed seasonal block (April–November on the mainland), identical across reference years, and the only timeslice whose window crosses the 1 July financial-year boundary. Peak and summer therefore sit wholly inside one reference year, so labelling them by start date is unambiguous; winter does straddle the boundary, but being invariant, which reference year "owns" its end can't change the result. So the decode needs no cross-reference-year or leap-day reconciliation — and tests fail if a future calendar breaks either property (a weather-varying window crossing 1 July, or winter differing between reference years).

src/ispypsa/templater/
  timeslices.py                                  → decode the PLEXOS on/off calendar → one window pattern per reference year
  plexos/7.5/timeslice_RefYear5000.csv           → the shipped PLEXOS timeslice calendar (v7.5)
  manually_extracted_template_tables/7.5/
    reference_year_sequence.csv                  → AEMO's planning-year → reference-year sequence
src/ispypsa/validation/schemas/timeslices.yaml   → schema for the templated table
tests/test_templater/test_timeslices.py

Not wired into the templater orchestrator yet.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/ispypsa/templater/timeslices.py	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[EllieKallmier]

I think this is one of those moot questions (assuming we can know the templater input pretty confidently), but is there a chance that this drops a planning year that doesn't have a complete occurrence of the same ref year?

[nick-gorman]

Yep, it's relying on the templater input having at least one complete year for each reference year.

[EllieKallmier]

Observation - This test structure seems a little different than others, testing the sub-functions just by calling the orchestrator with different input configurations, rather than testing each function explicitly. No comment really just noting in case there's a specific reasoning or preference behind this style!