Skip to content

Pins GenerationStream.group_by(period=) totals for a multi-month entry - #58

Merged
dylanjm merged 1 commit into
mainfrom
pr2-group-by-period-test
Oct 27, 2026
Merged

dylanjm merged 1 commit into
mainfrom
pr2-group-by-period-test

Conversation

@j-bryan

@j-bryan j-bryan commented Oct 27, 2026

Copy link
Copy Markdown
Collaborator

#35 reported that GenerationStream.group_by(period=) gave wrong period totals for entries spanning several periods. #42 (ef15517) already fixed this: it splits entries at calendar boundaries with _calendar_pieces, the same allocation to_revenue uses. This PR adds no library code. It adds a test that pins the fixed behavior with hand-computed values.

The test takes the issue's own case, one entry over [2027-01-01, 2027-08-01), and groups it by "month". It asserts:

  • seven groups whose MWh are in proportion to each month's days (31, 28, 31, 30, 31, 30, 31 of 212);
  • that the groups sum to the entry's total;
  • that to_revenue(1.0) gives the same amount for each month.

The expected values are literals, with no reimplemented oracle. Uneven multi-year proration is already pinned by the group_by docstring doctest (2030–2032), so there is no separate "year" test.

GenerationStream is being removed in the v1.0 primitives rework, so no further API is planned for it.

Result changes

None. Tests only.

Closes #35

🤖 Generated with Claude Code

…h entry (#35)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@dylanjm dylanjm left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New test nailing down group-by logic.

@dylanjm
dylanjm merged commit 0e23f45 into main Oct 27, 2026
1 check passed
@dylanjm
dylanjm deleted the pr2-group-by-period-test branch October 27, 2026 20:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

No built-in way to get appropriately annualized entries from a GenerationStream

2 participants