Repository navigation
Conversation
The printable fixtures page shows dates without a year, and parse_date guessed it from the current calendar year. That guess is only right while the current year equals the year the season started: from January 1 every date resolves one year forward, so all played matches look upcoming, /results goes empty and /next points at the season opener instead of the next game. current_season() in utils.py had the same flaw, feeding a wrong season into the fbref assists URL. Both now anchor on the season start year (July onwards = this year, otherwise last year). Behaviour between July and December is unchanged. Adds pytest scaffolding (conftest sys.path shim, dev dependency group, a tests workflow) and frozen-clock tests for the date logic. Three of the tests fail against the previous logic and pass now. Known limit, left deliberately: if the hardcoded season URL is bumped to the next season's page before July 1, dates on it resolve one year early until July. Fixing that needs the season threaded through from the URL, which belongs with removing the hardcoded URL itself.
ash663
force-pushed
the
fix/fixture-year-inference
branch
from
September 9, 2026 12:08
df74f61 to
32aee99
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The printable fixtures page shows match dates without a year ("Wed Feb 3 - 20:00"), so
parse_datehas to work the year out. Since #134 it guesses from the current calendar year:current_year if month >= 7 else current_year + 1. That guess is only right while the current year is the year the season started, i.e. August through December. From January 1 every date resolves one year forward.What that looks like in Discord from January until the season ends: every match on the page (played ones included) gets a future date, so
/resultsreturns an empty embed,/nextannounces the pre-season friendly from last August (dated next year) instead of the game actually days away, and/fixturescountdowns are off by a year. Reproduced by running the parser against a saved copy of the current page with the clock set to Jan 15 2027: 0 of 52 matches counted as played, "next match" = Club Friendlies on 2027-08-01. This hasn't bitten yet because the parser only landed in August — this January would have been its first.current_season()in utils.py has the same flaw (returns 2027-2028 in Feb 2027), which feeds a wrong season into the fbref assists URL.The fix anchors both on the season start year instead: July onwards counts as this year's season, January-June as the season that started the year before. Behaviour from July to December is unchanged.
Also adds minimal pytest scaffolding, since this is exactly the kind of bug a test server can't catch (nobody manually tests in January until it's January): a conftest shim for the
from utils import ...path convention, a dev dependency group (pytest, freezegun), frozen-clock tests for the date logic, and a small workflow that runs them on PRs. Three of the tests fail against the old logic and pass with this change; the rest pin current behaviour. More tests can come later — this is deliberately just the skeleton plus coverage for this bug.One known limit, left as is: if the hardcoded season URL is bumped to the next season's page before July 1, dates on that page resolve one year early until July. Doing better means passing the season through from the URL/page instead of inferring from the clock — that belongs with removing the hardcoded URL, which is a separate change (the women's page URL has no season in it, so it needs actual thought).