Summary
In the prepare_next_day optimization path, each period's timestamp is generated with today's date instead of tomorrow's, even though the schedule is for tomorrow.
Observed in debug bundle bess-debug-2026-06-20-235905.md (v9.6.0): the latest stored schedule was economically the next-day plan (its buy_price array fits the next-day price curve exactly), but every period row read 2026-06-20 HH:MM rather than 2026-06-21.
Root cause
core/bess/battery_system_manager.py:
- The
prepare_next_day branch of _gather_optimization_data sets optimization_period = 0.
_add_timestamps_to_period_data then calls period_index_to_timestamp(optimization_period + i) = period_index_to_timestamp(0..95), and time_utils.period_index_to_timestamp anchors index 0 to datetime.now().date() (today).
The period indices (0–95) are operationally correct — when the schedule is consumed the next day they line up with that day's periods. Only the date label in the timestamp is wrong.
Impact
- Cosmetic/operational-correctness: optimization and inverter writes are unaffected (they use indices), but the timestamps are misleading.
- Real debugging cost: it made a debug-log analysis initially misattribute the next-day schedule to the current day. Any tooling that reasons about period_data timestamps by date would be wrong by one day for next-day schedules.
Suggested fix (needs verification)
Make _add_timestamps_to_period_data aware of the next-day context and offset the date by one day for the prepare_next_day schedule, while keeping period indices at 0–95. Verify no consumer relies on the (incorrect) date matching today — daily_view_builder merges by index, and schedule_store uses its own time_utils.now() timestamp, so this looks safe but should be covered by tests.
Related
Summary
In the
prepare_next_dayoptimization path, each period'stimestampis generated with today's date instead of tomorrow's, even though the schedule is for tomorrow.Observed in debug bundle
bess-debug-2026-06-20-235905.md(v9.6.0): the latest stored schedule was economically the next-day plan (itsbuy_pricearray fits the next-day price curve exactly), but every period row read2026-06-20 HH:MMrather than2026-06-21.Root cause
core/bess/battery_system_manager.py:prepare_next_daybranch of_gather_optimization_datasetsoptimization_period = 0._add_timestamps_to_period_datathen callsperiod_index_to_timestamp(optimization_period + i)=period_index_to_timestamp(0..95), andtime_utils.period_index_to_timestampanchors index 0 todatetime.now().date()(today).The period indices (0–95) are operationally correct — when the schedule is consumed the next day they line up with that day's periods. Only the date label in the timestamp is wrong.
Impact
Suggested fix (needs verification)
Make
_add_timestamps_to_period_dataaware of the next-day context and offset the date by one day for theprepare_next_dayschedule, while keeping period indices at 0–95. Verify no consumer relies on the (incorrect) date matchingtoday—daily_view_buildermerges by index, andschedule_storeuses its owntime_utils.now()timestamp, so this looks safe but should be covered by tests.Related