The Days Since Counter calculates whole Gregorian calendar days between a named start date and the device's current local day, using UTC midnight math to avoid daylight-saving drift. A result that looks "wrong" almost always traces back to one of three places: the start date field, the meaning of the word "day," or the snapshot history attached to that start date. The page validates YYYY-MM-DD from 1900 through 9999, applies the divisible-by-4/100/400 leap-year rule (per the U.S. Naval Observatory), then subtracts integer day counts from Date.UTC values (per ECMA-262). Because the subtraction happens at UTC midnight, a local daylight-saving transition never turns a calendar gap into 23 or 25 hours. That means a start date such as 2024-02-28 reports two days on 2024-03-01, while the non-leap-year 2023-02-28 to 2023-03-01 gap reports one day. If the displayed number disagrees with your expectation, the fix is usually a corrected date entry, a clearer mental model of what "calendar day" means, or a deliberate reset of local history — not a bug in the tool itself.
What Days Since Counter Actually Counts
The counter is a calendar-day tool, not an elapsed timer. You enter a milestone name and a start date in YYYY-MM-DD form, the page parses the year, month, and day as separate numeric components, and the engine converts each into a UTC midnight timestamp before subtracting. The visible result on the page is the difference between those two timestamps expressed as whole days, attached to the device-local calendar day you are viewing. The number you read is therefore a count of midnights crossed, not hours, not minutes, and not working days. The distinction is worth understanding if you have ever compared the result to a phone calculator that returns an elapsed duration, because the two only agree on clean 24-hour periods with no DST shift involved. For a closer look at how a calendar-day count can diverge from an hours-based elapsed duration, see the guide on Days Since Counter calendar days vs 24-hour periods.
This matters because the most common "wrong" report is a number that disagrees with what a clock would have produced. A clock measures elapsed time; a calendar counts discrete day boundaries. When they disagree — for example, across a spring-forward Sunday — the counter is correct and the clock-based expectation is off by an hour. The tool documents this distinction so the result stays predictable regardless of where the device sits in the year.
Why a Result May Look Wrong
Most "wrong" reports come from a handful of predictable causes. Pinning down which one applies is the fastest path to a fix.
- Date format confusion. The field accepts a complete YYYY-MM-DD value. Slashes, two-digit years, or a swapped month/day position will not parse and may be rejected or produce a surprise.
- Mental model of "day." A calendar day is the unit the tool returns. If you expected an elapsed-hours total, a DST-spanning week, or a workday count, the number will look off by design.
- Leap-year edge cases. Late February into early March is a common surprise: a leap year shows an extra day compared to the previous year, and any calculation that ignores Feb 29 will be wrong by one.
- Stale snapshots. Saving a snapshot, then changing the start date later, leaves old history attached to the old date. The page will prompt you to clear local history before letting a new start date rewrite old entries.
- Future date attempts. The tool only accepts current or earlier dates and will reject a future value rather than silently switching into a countdown.
If none of these fit, the discrepancy usually comes from comparing two different definitions of "today" — the device-local day used to display the result versus a remote calendar in another time zone.
How to Fix a Wrong-Looking Result
- Open Days Since Counter and locate the milestone name and start date fields.
- Re-enter the start date in strict YYYY-MM-DD form, with a four-digit year between 1900 and 9999, a two-digit month, and a two-digit day. Watch for off-by-one transpositions such as 2024-03-01 typed as 2024-01-03.
- Confirm the milestone name is short and descriptive. The name is a private label and is not part of the calculation, but it keeps the history readable.
- Save the milestone. The page validates the date, applies the leap-year rule, and displays the number of whole Gregorian calendar days between the start date and the device-local day you are viewing.
- Read the result as calendar days, not hours. If your expectation was built from a clock across a DST transition, recalculate using the local calendar date rather than elapsed time.
- If you have existing snapshots and want to change the start date, clear local history first. Saving a new start date over old snapshots would silently change what the old entries mean.
- Once the displayed number matches your calendar expectation, use Save today's snapshot to lock the current local day as a dated record. Re-open the page on a future visit and save another snapshot whenever you want a new dated row.
- If you want a file outside the browser, export PNG (a 1080 by 1350 summary without your custom milestone name or a web address) or CSV (Snapshot date, Start date, Days since columns) directly from the page.
When to Clear Local History vs. Keep Snapshots
Snapshots belong to one start date. The tool asks you to clear local history before replacing a start date that already has snapshots, because each saved row has meaning only with the date it was originally paired with. Clearing history is the right move when the milestone itself has changed — for example, you started tracking a project kickoff, then realized you actually wanted a maintenance interval from a different date. In that case, clear local history first, then enter the new milestone name and start date.
Keeping snapshots is the right move when the milestone is the same and you simply want to record another dated reading. A snapshot can legitimately be zero when the milestone starts today, and the history list keeps those zero-day rows visible so you do not lose the "this just began" entry. To add another reading without disturbing anything, return on a later local day and use Save today's snapshot; the start date and existing rows stay put.
Clearing is irreversible inside the browser, so export a CSV first if you want a spreadsheet copy before you reset. The export uses native canvas and Blob APIs in the browser; nothing is uploaded, and the file is created on your device.
Saving and Exporting a Verified Result
Once the displayed number matches what your calendar arithmetic predicts, the next step is making the result durable. Save today's snapshot records the device-local day you are viewing, the start date, and the integer day count together as one row. Because the display is anchored to the device-local day, the same start date saved on two different devices, or across a trip, may produce different snapshot dates — that is intentional and keeps each entry tied to the local calendar the reader was using at the time.
The CSV export writes three columns: Snapshot date, Start date, and Days since. That is enough context for a spreadsheet to interpret each row without needing the browser tab open. The PNG export builds a 1080 by 1350 image with a total for the active local day and recent snapshots; it deliberately omits your milestone name and any web address, so the file is shareable without exposing personal labels. Both files are created in-browser; the milestone name, start date, and snapshots never leave the device and are not joined to a profile.
If browser storage is unavailable, the calculation still works and the page tells you it cannot retain snapshots. In that state, export immediately after each snapshot if you want any record to survive a reload.
Quick Troubleshooting Reference
| Symptom | Likely cause | Fix in Days Since Counter |
|---|---|---|
| Result is off by one across late February | Leap-year rule adds Feb 29 in years divisible by 4 (except centuries not divisible by 400) | Re-enter the start date in YYYY-MM-DD; verify the gap against the documented leap-year rule |
| Result looks off by an hour, not a full day | Mental model used elapsed hours instead of calendar days | Reread the displayed number as whole calendar days, not as an elapsed duration |
| Field rejects the date you entered | Future date, or month/day out of range, or year outside 1900–9999 | Enter a current or earlier valid YYYY-MM-DD between 1900 and 9999 |
| Old snapshots disagree with the new total | Start date was changed after snapshots already existed | Export CSV first, then clear local history before re-entering the new start date |
| Two devices show different "today" totals for the same start date | Each result is anchored to the device-local day used for the snapshot | Treat each device's snapshot row as belonging to its own local calendar day |
Verifying the Fix With One Worked Example
Cross-checking one boundary date against a known rule is the fastest way to confirm the tool is working as documented. Take the start date 2024-02-28 (a leap year, divisible by four and not a century year) and read the result on the device-local day 2024-03-01. The engine converts both dates to UTC midnight timestamps and subtracts:
Formula: (Date.UTC(year, month − 1, day) / 86400000) for each date, then subtract.
Substituted: (Date.UTC(2024, 2, 1) / 86400000) − (Date.UTC(2024, 1, 28) / 86400000) = (N + 2) − N
Result: 2 days
Running the same arithmetic for the non-leap year 2023-02-28 → 2023-03-01 gives 1, because 2023 is not divisible by four. If your local copy reads 2 for the 2024 boundary and 1 for the 2023 boundary, the counter is behaving correctly and the original "wrong" feeling was a calendar-vs-elapsed mismatch rather than a calculation error.
If you're weighing options, Key Press Counter on iPhone: Count Keys in Safari covers this in detail.