Comment by Yunus Emre Vurgun on "How I made a habit tracker that doesn't lie in February"

Locking the nonexistent days is the clever part, since it makes the >100% bug impossible instead of just hiding it. One thing to watch in the current month: dividing by DAY(EOMONTH()) makes your rate look low until the month ends, so a second column with COUNTIF(row,TRUE)/MIN(DAY(TODAY()),DAY(EOMONTH(B1,0))) gives a fair "so far" number. For Excel, EOMONTH behaves the same, but checkbox cells may come back as TRUE/FALSE or 1/0 depending on how they're inserted, so COUNTIF on TRUE is worth retesting there.

Thanks Yunus — locking nonexistent days is exactly how I wanted to kill the >100% case instead of papering over it. You're right that a full-month DAY(EOMONTH()) denominator understates the current month until it ends; a separate "so far" column with MIN(DAY(TODAY()), DAY(EOMONTH(...))) is a clean fix, and I'll call that out. Good catch on Excel checkboxes too — TRUE/FALSE vs 1/0 depends on how the cells were inserted, so COUNTIF on TRUE needs a retest there.

Quick follow-up: v1.8 now has a separate "So far" column that divides by MIN(DAY(TODAY()), days in the month), and the counts accept both TRUE and 1. I checked it in LibreOffice; Excel is still untested on my side. Thanks again for the nudge.

Nice, accepting both TRUE and 1 makes it work in more places. If you test it in Excel, try a sheet with a day after today already ticked: MIN(DAY(TODAY()),...) caps the denominator but not the count, so a pre-ticked future day can still push "so far" above 100%. Using COUNTIFS limited to dates on or before TODAY() fixes that.

Search Hashnode