A book started and finished the same day can't be marked "read"

Nobody has started this yet — be first.

Business impact

This app exists to let someone log what they've read -- including a novella or a short book finished in a single sitting, which is not an edge case for a lot of readers, it's normal. Right now the API flatly refuses to let anyone record that: every same-day read gets rejected with a confusing error claiming the finish date is "before" the start date, when the user typed the exact same date in both fields. The workaround (back-date one of the two fields by a day, so the log is now factually wrong) is exactly the kind of "the tool doesn't trust my own data" moment that makes people stop using a tracker.

Problem

POST /api/books/ with status="read", date_started and date_finished both set to the same date returns 400 Bad Request with {"date_finished": ["date_finished cannot be before date_started."]}.

Current behavior

A same-day read is rejected with an error message that claims the finish date is before the start date, even though the two dates are identical.

Expected behavior

date_finished == date_started is valid and must be accepted (201). Only date_finished strictly before date_started should be rejected -- which is exactly what the error message already claims to check for.

Steps to reproduce

cd django/library_tracker source ../library_tracker_venv/bin/activate python manage.py shell -c " from rest_framework.test import APIClient c = APIClient() r = c.post('/api/books/', { 'title': 'One-Day Read', 'author': 'Someone', 'status': 'read', 'date_started': '2026-03-10', 'date_finished': '2026-03-10', }) print(r.status_code, r.data) "

-> 400 {'date_finished': ['date_finished cannot be before date_started.']}

Why this matters

This exact rule is implemented twice in this codebase: once in books/serializers.py (BookSerializer.validate, which is what the API actually runs on every request) and once in books/models.py (Book.clean, which the DRF create/update path never calls -- DRF writes straight to the database via Model.objects.create()/.save(), it does not call full_clean()). The two copies have drifted: one uses < (same-day is fine) and the other now uses <= (same-day is rejected). Reading the serializer alone looks internally consistent -- the bug only shows up when you notice it disagrees with the model's own version of the same rule.

Suggested approach

Compare the date comparison in BookSerializer.validate() (books/serializers.py) against the equivalent check in Book.clean() (books/models.py). They're meant to enforce the same rule; only one of them is currently correct.

Acceptance criteria

date_finished == date_started is accepted (201).
date_finished one day before date_started is still rejected (400) -- don't just delete the check.
The comparison in the serializer matches the one in Book.clean().
practicetickets/test_ticket04_same_day_finish_rejected.py passes.

Verification

python manage.py test practicetickets.test_ticket04_same_day_finish_rejected -v 2

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/same-day-finish-rejected

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/same-day-finish-rejected

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

Library Tracker — A Django REST Framework Reading Log

A compact Django + DRF book-tracking API where the same handful of business rules -- a rating is 1-5, a read book needs a finish date -- are deliberately enforced at three independent layers (model validators, serializer validation, a database CheckConstraint), and the interesting bugs live in the gaps between them.

Fork on GitHub

Download

Setup

Library Tracker — A Django REST Framework Reading Log

git clone <your-fork>
cd <your-fork>/django/library_tracker
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

python manage.py migrate
python manage.py createsuperuser
python manage.py runserver

The API is then at and the admin at . , , and are read from the environment with sensible local defaults -- no secrets are hardcoded.