Days Since Counter 是一個以瀏覽器為基礎的日曆工具，用來回答一個精確的問題：從一個具名的起始日期到這台裝置上的今天，總共經過了多少個完整的格里曆日子。這個數字是透過驗證你輸入的 YYYY-MM-DD 格式、把兩個端點都換算成 UTC 午夜的整數，再相減得出的，這代表結果永遠是以日曆天數表示，而不是以 24 小時為一單位的區間。這個區別很重要，因為當你要測量的區間內剛好碰到日光節約時間的轉換、閏日，或跨月邊界時，24 小時碼表和以日曆天數計算的計數器，在這些邊界附近會給出不一樣的答案。這個工具會把你的里程碑名稱、起始日期，以及帶日期的快照，保存在私密的本機瀏覽器儲存空間中，直接從你的裝置產生 PNG 或 CSV 匯出檔，並且會拒絕任何未來的起始日期，而不是悄悄變成一個倒數計時器。只要在這樣的前提下使用，它就能取代那種每天早上手動遞增一個數字的不可靠習慣，也能取代那種在不查證的情況下，直接相信手機上「幾天前」標籤的更不可靠習慣。
在這個工具裡，「days since」真正的意思是什麼
一個天數計數器，並不是一個披著日曆外皮的碼表。這個產品的設計原則明確指出，計算所使用的是在 UTC 午夜驗證過的格里曆日期組成，所以你看到的數值，是日曆網格上兩個日期之間的整數差距，而不是以小時、分鐘、秒為單位所計算出的經過時長。這個設計選擇，出於兩個實際的原因。
第一，日光節約時間的轉換，會從結果中消失。在一個會調快或調慢時鐘的國家，用本機時鐘相減，可能會讓大多數人口中的「一天」變成 23 或 25 小時。透過把兩個端點都換算成 UTC 午夜，這個工具能讓答案和牆上日曆印出的日期保持一致，所以無論中間是否發生時鐘調整，同樣是從週三到週四的間隔，讀出來都會是一天。
第二，一個天數計數器，永遠不會宣稱這個里程碑本身具有什麼意義。這個頁面不會去解讀你的專案啟動日、習慣重置，或維護週期究竟代表什麼，也不會主張這個日期具有法律、財務、醫療或合約上的意義。它單純回答你輸入的那個日曆問題，然後把判斷留給你自己。想更深入了解日曆天數與 24 小時區間之間的差異，專門的comparison of calendar days and 24-hour periods會把兩種計算方式並排說明。
會讓一個天數計數器出錯的常見誤區
大多數天數計數器出錯的原因，都是把它當成別的東西來用。以下是一些反覆出現的常見錯誤，以及這個工具的設計如何加以阻止。
- 要求一個未來的起始日期。如果一個「距今多少天」的工具，會在你把年份打錯時，悄悄變成一個倒數計時器，那它就沒有用了。這個計數器會拒絕任何晚於裝置本機當日的日期，並要求你重新輸入一個數值，這樣它所回答的問題才能保持一致。future start date guide完整展示了驗證訊息實際上會是什麼樣子。
- 把這個數字讀成經過的小時數。有些人會以為 27 天代表 27 乘以 24 小時。事實並非如此。這個數字是一個日曆天數的差距，所以即使一段區間跨越了春天調快或秋天調慢的轉換，每經過一條日曆線，仍然只算作一天。
- 在已經存在快照之後，修改起始日期。已儲存的快照會被固定在它們原本的起始日期上，因為把它們重新指向一個新的日期，會悄悄改寫每一筆先前紀錄的意義。這個工具會阻擋這個動作，並要求你先清除本機歷史紀錄；一旦清除完成，新的起始日期與它的第一筆快照，就會開始一份全新的紀錄。
- 把結果為零的天數，當成一個空白結果來看待。當你的里程碑從今天開始時，答案真的就是零，而這個零會被保留在歷史清單中，而不是被隱藏起來，所以你開始的那一天會留存在紀錄上。
- 忘記在之後的造訪時儲存快照。第一次儲存，是在你建立這個計數器時發生的，所以第一天永遠會被記錄下來。之後的造訪，只有在你點擊「Save today's snapshot」時，才會新增一筆快照，這是你之後可以回頭參考的、帶日期的本機紀錄。
- 忽略瀏覽器的儲存空間限制。快照只存在於這個瀏覽器中。如果儲存空間無法使用，這個頁面仍然會計算天數，但會告訴你它無法保留這筆快照。
一旦你理解了這套設計原則，實際的設定過程就很簡短，而且每一個步驟，都直接對應到上面提到的那些常見錯誤。
- 輸入一個你之後還能認得出來的簡短里程碑名稱，例如「Garage reorganization」或「No-soda month」，並選擇一個 YYYY-MM-DD 格式、今天或更早的起始日期。這個日期欄位會驗證四位數的年份是否落在 1900 到 9999 之間、該月份的天數，以及格里曆的閏年規則，所以像 2025-02-30 這樣的無效日期，會在任何計算開始之前就被拒絕。
- 儲存這個起始日期。儲存動作會為今天建立第一筆快照，這是之後每一次比較的錨點，也證明這個計數器確實是從你打算開始的那一天算起的。
- 閱讀頁面上顯示的格里曆日曆天數結果。這個數字，是你的起始日期與裝置本機當日之間的整數天數差距，是以 UTC 午夜為基準計算出來的，所以日光節約時間的調整不會改變它。
- 只要你想留下一筆帶日期的本機紀錄，就可以在之後的造訪時使用「Save today's snapshot」。每一筆快照都是本機歷史紀錄中的一列，包括你在開始的當天就儲存時所產生的零天紀錄。
- 只要還存在任何歷史紀錄，就讓起始日期保持不變。如果你真的需要換一個里程碑，請先清除本機歷史紀錄，這樣新的起始日期才不會改寫掉較舊的紀錄。
- 只有在你需要瀏覽器之外的檔案時，才匯出 PNG 或 CSV。PNG 是一張 1080 乘 1350 的摘要圖，CSV 則包含 Snapshot date、Start date 與 Days since 三個欄位，兩者都是透過 canvas 與 Blob API 在本機產生的。
- 照這個工具設想的方式來解讀結果
這個計算有兩個部分，很容易被人視為理所當然：日期驗證與整數相減。驗證所依循的規則是：能被四整除的年份是閏年，但不能被 400 整除的世紀年除外。這正是美國海軍天文台針對格里曆所記載的同一條規則，也是為什麼 2024-02-29 這一天存在、而 2023-02-29 不存在的原因。一旦日期的各個組成部分通過驗證，這個工具就會用 Date.UTC(year, month - 1, day) 除以 86,400,000 毫秒，把你的起始日期與目前的本機日期都換算成 UTC 午夜的整數，然後相減。
實際範例：從 2024-02-28 到 2024-03-01 這個跨越閏年的間隔，計算方式是 Date.UTC(2024, 2, 1) / 86,400,000 減去 Date.UTC(2024, 1, 28) / 86,400,000。因為 2024 年是閏年，2 月 29 日正好落在這兩個端點之間，所以相減的結果是 2 個日曆天。同樣的相減方式，套用在 2023-02-28 到 2023-03-01 上，結果則是 1 個日曆天，因為 2023 年沒有 2 月 29 日可以計入。
這套流程會產生一些讓習慣看手機上「x 天前」標籤的人感到意外的結果：
| 目前的本機日期 | 差距（日曆天） | 原因 | |
|---|---|---|---|
| 2024-03-01 | 2 | 2024 年是閏年，所以 2 月 29 日正好落在兩者之間 | |
| 2023-03-01 | 1 | 2023 年不是閏年，所以 3 月 1 日緊接著到來 | |
| 2024-01-01 | 0 | 同一個日曆日，零是一個真實的結果 | |
| 2025-11-02 | 2 | 在許多地區跨越了日光節約時間的邊界，仍然是兩個日曆天 |
ECMA-262 Date.UTC specification，至於規則本身，則可參閱U.S. Naval Observatory leap-year reference。
快照、歷史紀錄與匯出功能，如何讓紀錄保持可信一個計數器可不可信，完全取決於它背後的歷史紀錄。這個產品的設計原則指出，快照是儲存在鍵值 counter:days-since-counter 底下的私密瀏覽器資料，沒有帳號、沒有遠端日期服務、沒有上傳佇列，也不會在裝置之間同步。清除這個網站的瀏覽器資料，會把整份紀錄完全移除，而在另一個瀏覽器中，這個計數器則會從空白開始，所以快照清單，就是那個瀏覽器裡唯一可信的真相來源。
有兩條規則能讓這份歷史紀錄保持可讀。第一，快照的值可以是零，而零天的快照仍然會保留在清單中可見。如果你的里程碑從今天開始，而你儲存了一次，那一列就會顯示 0 天，這對你開始的那一天來說是正確的答案，也是你之後比對後續紀錄時很有用的錨點。第二，歷史紀錄屬於單一一個起始日期，所以在你切換里程碑之前先匯出，能保護舊的紀錄不被覆寫。CSV 匯出檔是一個小檔案，包含 Snapshot date、Start date 與 Days since 三個欄位，足以讓試算表或封存工具解讀每一列內容，而不必依賴僅限瀏覽器內部使用的標籤。PNG 匯出檔是一張 1080 乘 1350 的摘要圖，刻意省略了你自訂的里程碑名稱與網址，藉此限制一張可分享圖片中所包含的個人情境資訊。如果瀏覽器的儲存空間無法使用，計算仍然照常運作，但頁面會告訴你它無法保留快照，這樣你就知道要在離開分頁之前，先把任何重要的內容匯出。
什麼時候這不是合適的工具
當你要問的問題，已經不再是「從 X 算起經過了多少個日曆天」時，一個天數計數器就不是合適的工具。一張簡短的比較表，能幫你選出正確的工具。
| 請使用 | |
|---|---|
| Days Since Counter | |
| Online Stopwatch | |
| Online Tally Counter |