Monthly summary drops expenses dated the last day of the month

Nobody has started this yet — be first.

Business impact

Every user's month-end summary -- and every category budget-warning check, which reuses this exact date math -- silently undercounts spending by excluding anything dated on the final calendar day of the month. A user who pays rent or a subscription on the 30th/31st sees a "total spend this month" that's simply wrong, and -- worse -- a user relying on the budget-warning feature to catch overspending can blow through their limit on the last day of the month and never get warned, silently defeating the one feature that exists to prevent exactly that.

Problem

monthRange computes a half-open date range [start, end) used as expense_date >= start AND expense_date < end. end is currently computed one day too early -- the range stops on the second-to-last day of the month -- so anything dated the actual last day falls outside it.

Current behavior

An expense dated the last day of a month is silently missing from that month's summary total and category breakdown, as if it never happened.

Expected behavior

monthRange("2026-08") returns ("2026-08-01", "2026-09-01") -- a half-open range correctly covering every day of August, including the 31st.

Steps to reproduce

As an authenticated user, POST /expenses with expense_date: "2026-08-31". GET /expenses/summary?month=2026-08

Expected: the expense is included in total and its category's breakdown.

Actual: it's missing entirely.

Why this matters

Half-open ranges are the standard way to do correct, inclusive month-boundary math with plain date comparisons -- this is a boundary/off-by-one error in how end is derived from start.

Suggested approach

Look at how end is computed from start in monthRange and think about what date represents "the first moment of the next month" relative to start.

Acceptance criteria

An expense dated the 1st of a month appears in that month's summary.
An expense dated the last day of a month appears in that month's summary too.
An expense dated the 1st of the next month does not leak into the prior month's summary (don't overcorrect the other direction).
The same fix applies to Handler.budgetWarning, which calls the same function -- a budget-limited category's spend on the last day of the month must count toward triggering the warning.

Verification

go test ./practicetickets/... -run TestTicket02 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/month-summary-drops-last-day

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/month-summary-drops-last-day

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Expense Tracker — SQL-Enforced Multi-User Isolation

A production-style multi-user expense tracker in Go where the authorization boundary between one user's financial data and everyone else's is a literal SQL `WHERE id = $1 AND user_id = $2` clause -- not an application-layer check -- so a single flipped operator or dropped predicate is a real, silent cross-account data breach, not a cosmetic bug.

Fork on GitHub

Download

Setup

Expense Tracker — SQL-Enforced Multi-User Isolation

git clone <your-fork>
cd expense_tracker
docker compose up --build   # postgres (host port 5434) + app (host port 8082)

auto-applies on first boot via Postgres's mechanism, seeding the seven global default categories (ids 1-7). The compose project is named , so it won't collide with sibling projects on the same machine. Health-check on gates 's startup so the API never starts before the schema exists.