How the HCM Handles Leap Years
The HCM models every year as a standard 365-day year. Every profile is a fixed 17,520-interval (365-day) year, applied by interval position, not by calendar date - so each modelled year has identical intervals and is directly comparable. The HCM never models a 366th day.
This means:
- A leap base year is limited to 365 days of load data (one day is dropped).
- A leap simulated year produces 365 days of results (the final calendar day is not produced).
- In a leap simulated year, raw data results from 29 February onward are labelled one day earlier. This only affects the date label on raw data rows, not aggregate metrics (energy, peaks, hours outside limits) such as those in Network Performance Metrics Enhanced.
Customer load data
For the reference AMI load data window, the total time can not be more than 365 days, meaning a full calendar year in a leap year will not be accepted.
To use a leap year such as 2024 as your base, request at most 365 days, eg:
start_time = 2024-01-01T00:30
end_time = 2024-12-31T00:00
This example covers 1 January to 30 December: 29 February is included, 31 December is not. Remember that intervals are time-ending - see time conventions.
Choose which day you want to leave off - typically it is not an issue to leave off the 31st of December or 1st of January as those are unlikely to be peak demand days.
The demand-forecast base year is taken from the final timestep of the window, so a window ending exactly on 1 January counts as the following year. See HCM Scenarios for more information.
Scenario and intervention profiles
DER profiles (PV, EV, BESS) are normalised 17,520-interval arrays applied by position. Shorter profiles are extended by repeating their daily pattern; longer ones are trimmed to 365 days. Best practice is to supply exactly 17,520 values.
Interventions are scoped by whole-year year range and use the same 365-day profiles, so leap years need no special handling.
Results and the leap-year date shift
If raw/timeseries output is enabled, every interval gets a result row, timestamped by real elapsed time from 1 January. Dates align up to 28 February. After the inserted 29 February, each profile day is labelled one day earlier than its non-leap date. Aggregate metrics are unaffected - this matters only when matching a single raw timestamp to a real calendar date.
| Nominal day | Leap year | Non-leap year |
|---|---|---|
| Day 59 | 28 Feb | 28 Feb |
| Day 60 | 29 Feb | 1 Mar |
| Day 345 | 10 Dec | 11 Dec |
| Day 365 | 30 Dec | 31 Dec |
| Day 366 | Not modelled | Not modelled |
To compare raw results for a leap and non-leap year like-for-like, shift the leap year +1 day from 1 March onward.
Combining base and simulated years
| Base year | Simulated year | Result |
|---|---|---|
| Non-leap | Non-leap | Full year, no adjustment. |
| Leap | Non-leap | Base data loses one day (eg 31 Dec); results cover the full year. |
| Non-leap | Leap | Results stop one day short; dates offset by one day from 29 Feb. |
| Leap | Leap | Base data loses one day (eg 31 Dec), and results stop one day short with dates offset by one day from 29 Feb. |
If you would like to explore changes to the leap year logic to align with your particular use cases, contact Zepben for further discussion.