A Days Since Counter documents a milestone by saving a named start date in YYYY-MM-DD format and then creating a dated Gregorian calendar-day snapshot on each local day you revisit the page, so the first and most important step to document is writing down that milestone name, that start date, and every snapshot date you saved. Documentation for this tool is not a running tally you increment by hand; it is a small, structured set of fields that match exactly what the page already records for you. Once you capture the milestone label, the validated start date, and the device-local snapshot date attached to each saved count, the result is portable: it can be copied into a note, pasted into a spreadsheet, or exported directly as PNG or CSV without an account or server upload. That portability is what turns a private browser record into a documented workflow you can reread, audit, or hand to someone else without losing the meaning of the numbers. The Days Since Counter tool already does most of this for you; the task here is choosing which fields to keep and where to keep them outside the browser.
Why a Personal Workflow Record Helps
Most calendar counting starts informally: someone writes a number in a notes app, adds one the next morning, and a few weeks later cannot remember which date the count actually started. A written record fixes that problem at the source by pinning down the inputs before the running count can drift. With a Days Since Counter the drift risk is lower because the tool computes whole Gregorian calendar days from the start date you entered, but the inputs themselves (the milestone name, the validated start date, the saved snapshot dates) still live only in your private browser storage. A document gives those inputs a home outside the browser so they survive clearing site data, switching devices, or losing access to the original profile. A record also turns the tool from a one-off answer into a repeatable procedure: the next time you begin a milestone, you already know which fields to copy, which exports to save, and which dates to verify.
What to Capture in Each Step
Documentation is only useful if the fields you write down map directly to something the tool produced. The Days Since Counter accepts a short milestone name and a YYYY-MM-DD start date in the range 1900 through 9999, validates month and day against the Gregorian leap-year rule, and then displays a whole number of days on the device-local calendar day. Snapshots, PNG, and CSV exports all flow from those same fields. A short comparison table makes the mapping explicit and gives the workflow a checklist you can reuse.
| Field | What to record | Where it comes from |
|---|---|---|
| Milestone name | Short label you typed (for example, "Project kickoff" or "Routine change") | Tool text input |
| Start date | Complete YYYY-MM-DD value, year between 1900 and 9999 | Tool date input, validated |
| Snapshot date | Local calendar day the Save today's snapshot button was pressed | Tool output, browser-local |
| Days since | Whole Gregorian calendar days from start date to snapshot date | Tool output, computed at UTC midnight |
| Export file | PNG (1080 by 1350 summary) or CSV (Snapshot date, Start date, Days since) | Tool action, native browser download |
That five-row checklist is the entire documentation surface for a Days Since Counter workflow. Anything outside these fields either repeats information already captured or adds interpretation the tool deliberately avoids (the page does not assign legal, financial, medical, or contractual meaning to a milestone).
How to Document the Steps You Use for Days Since Counter
- Open the Days Since Counter page and type a short milestone name into the milestone field. Write that exact label into your record so the document stays anchored to one event.
- Enter the start date as a complete YYYY-MM-DD value, choosing a current or earlier date (future values are rejected). Copy the verified value into your record; do not paraphrase it as a relative phrase like "last Tuesday" because the tool validates the components.
- Read the displayed whole number of Gregorian calendar days on the device-local calendar day. Note both the number and the local viewing date, since the count is attached to that day rather than to a moment in time.
- Click Save today's snapshot whenever you want a dated record of the count. Each press creates a new row tagged with the local snapshot date and the current days-since value; copy that row into your document or rely on the in-browser history list.
- Decide whether to export now or wait. PNG creates a 1080 by 1350 image without your milestone name or a web address, which limits personal context in a shareable file. CSV creates a simple file with three columns (Snapshot date, Start date, Days since) that any spreadsheet can reopen. Save either export into the same folder as your written record.
- If you ever change the start date, clear local history first. Snapshots have meaning only with their original start date, so a new start date without a clear would silently rewrite the meaning of every saved row.
- Repeat the Save today's snapshot and export steps on later visits so the document grows into a dated history rather than a single static entry.
Use Snapshots and Exports as Built-In Documentation
The most reliable form of documentation is the export, because the file travels outside the browser. Export CSV is the better choice for a long-running record: the three-column layout (Snapshot date, Start date, Days since) gives every saved value enough context to be read on its own, without relying on a browser-only label. Export PNG is the better choice for a single shareable summary, since the image includes a total for the active local day and recent snapshots at a fixed 1080 by 1350 size, but the image deliberately omits your custom milestone name and any web address, which limits the amount of personal context embedded in the file. Both exports are generated directly in the browser through native canvas and Blob APIs, so no upload queue or server-side date service is involved in producing the file. A good habit is to export CSV once per milestone and rename the file with the milestone name so the durable copy is identifiable without depending on a notes app. If you also want a quick visual summary for a message or slide, add a PNG export at the same milestone checkpoint.
Verify the Calendar Rule Once
A single worked numeric example is worth documenting, because it proves the calendar rule the tool applies. The rule, as published by the U.S. Naval Observatory, is that a year divisible by four is a leap year, except century years unless they are divisible by 400. With 2024-02-28 as the start date and 2024-03-01 as the local viewing day, the calculation is Date.UTC(2024, 2, 1) - Date.UTC(2024, 1, 28), divided by 86400000, which is 2 days, because 2024 is a leap year and February 29, 2024 exists between the two dates. Compare that with the non-leap year 2023-02-28 to 2023-03-01: Date.UTC(2023, 2, 1) - Date.UTC(2023, 1, 28), divided by 86400000, is 1 day, because 2023 is not divisible by 4 and February has only 28 days. Writing those two lines into your record demonstrates that the tool counts whole calendar days using UTC midnight values rather than local hours, which is what protects a calendar gap from being misread as 23 or 25 hours during a daylight-saving transition. If you want a deeper walk-through of what the count actually represents, the guide on checking the result after using Days Since Counter pairs naturally with this workflow.
Keep the Documentation Private and Portable
Privacy is part of the documentation, not a separate concern. The tool stores your milestone name, start date, and snapshots only under local browser storage with no account, no server-side date service, no upload queue, and no remote calculation; the data is not sent to Lizely, synchronized across devices, or joined to a profile. That means your exported CSV and any notes you keep are the only durable copies of the milestone. The simplest portable layout is a single folder per milestone containing the CSV export, an optional PNG export, and a short text note with the milestone name and the start date. Clearing this site's browser data removes the in-browser record, and a second browser begins with an empty counter, so anything not exported is gone. If browser storage is unavailable when you visit, the displayed calculation still works and the page reports that it cannot retain snapshots, which is itself a documentation signal: write "no snapshot stored" next to that day's entry so the absence is visible in the record.
When to Restart the Documentation Cycle
Begin a new cycle when the previous milestone's purpose has ended, or when you want to track a different named event from a different start date. A new cycle should always include clearing local history first; the tool enforces this because saved snapshots have meaning only with their original start date, and silently reusing the same history under a new start date would let one number stand for two different milestones. Once the history is cleared and a new start date is saved, the next snapshot becomes the first row of the new cycle, and a freshly exported CSV replaces the old durable copy. Keeping the cycles separated in the record (one folder per milestone, one CSV per milestone) is what lets a long-running document stay readable months later.
Related reading: How to Decide If You Need a Knitting Row Counter.