「自從計數器」會計算指定起始日期與裝置當地日期之間的整個格里高利曆日數，採用 UTC 午夜運算以避免日光節約時間造成的誤差。當結果看起來「不對」時，幾乎都能追溯到以下三個地方之一：起始日期欄位、「日」這個字的意義，或是該起始日期所附加的快照紀錄。本頁會驗證 1900 到 9999 之間的 YYYY-MM-DD 格式，套用除以 4／100／400 的閏年規則（依據 美國海軍天文台），然後從 Date.UTC 的數值中扣減整數日數（依據 ECMA-262）。由於扣減發生在 UTC 午夜，本地日光節約時間的切換永遠不會把一個曆日差距變成 23 或 25 小時。這代表像 2024-02-28 這樣的起始日期在 2024-03-01 會顯示兩天；而非閏年的 2023-02-28 到 2023-03-01 差距則顯示一天。如果顯示的數字與你的預期不一致，修復方式通常是更正日期輸入、釐清「曆日」的概念，或是刻意重置本地紀錄——而非工具本身的錯誤。
「自從計數器」實際計算的內容
這個計數器是曆日工具，而非經過時間計時器。你輸入里程碑名稱與 YYYY-MM-DD 格式的起始日期後，本頁會將年、月、日解析為個別的數值元件，然後引擎會把每個元件轉成 UTC 午夜時間戳再進行扣減。頁面上顯示的結果就是這兩個時間戳之間的差距，以整日表示，並附加在你正在檢視的裝置當地日期上。因此你讀到的數字代表跨越了多少個午夜，而非小時、非分鐘，也非工作日。如果你曾經把這個結果與手機上回傳經過時長的計算機比較，就值得理解這個差異，因為兩者只有在沒有日光節約時間影響的整 24 小時區段才會一致。若想進一步了解曆日計算為何會與以小時為單位的經過時長不同，請參閱「自從計數器」曆日 vs 24 小時區段指南。
這點很重要，因為最常見的「錯誤」回報，是數字與時鐘所產生的結果不一致。時鐘測量的是經過時間；日曆則計算離散的日期界線。當兩者產生分歧——例如橫跨一個春令日光節約週日——計數器是正確的，而基於時鐘的預期則會差了一小時。工具會記錄這項差異，確保結果不論裝置位於年度哪個時段都保持可預測。
結果為何可能看起來錯誤
大多數「錯誤」回報都來自幾個可預測的原因。釐清是哪一個，是最快的修復途徑。
- 日期格式混淆。欄位接受完整的 YYYY-MM-DD 數值。斜線、兩位數年份或月日位置互換都無法解析，可能會被拒絕或產生意外結果。
- 對「日」的概念模型。曆日就是這個工具回傳的單位。如果你預期的是經過小時總數、橫跨日光節約時間的一週，或是工作日數，數字看起來當然會與預期不符。
- 閏年邊界情況。二月下旬進入三月初是常見的意外：閏年比前一年多顯示一天，任何忽略 2 月 29 日的計算都會差一天。
- 過時的快照。儲存快照後再更改起始日期，會讓舊紀錄仍然附加在舊日期上。本頁會提示你清除本地紀錄，才會讓新的起始日期改寫舊紀錄。
- 嘗試輸入未來日期。工具只接受當天或之前的日期，若輸入未來日期會被拒絕，而不會默默切換成倒數計時。
如果以上都不適用，差異通常來自對「今天」的兩種不同定義——顯示結果所用的裝置當地日期，以及另一時區的遠端日曆。
如何修正看似錯誤的結果
- 開啟「自從計數器」並找到里程碑名稱與起始日期欄位。
- 以嚴格的 YYYY-MM-DD 格式重新輸入起始日期，四位數年份需介於 1900 到 9999 之間，兩位數月份、兩位數日期。注意像是把 2024-03-01 打成 2024-01-03 這類的移位錯誤。
- 確認里程碑名稱簡潔且具描述性。名稱屬於私人標籤，不會參與計算，但能讓紀錄保持易讀。
- 儲存里程碑。本頁會驗證日期、套用閏年規則，並顯示起始日期與你正在檢視的裝置當地日期之間的整個格里高利曆日數。
- 將結果視為曆日，而非小時。如果你的預期是來自跨越日光節約時間切換的時鐘，請改用本地日曆日期重新計算，而非使用經過時間。
- 若已有快照並想更改起始日期，請先清除本地紀錄。以新起始日期覆蓋舊快照會在無聲無息中改變舊紀錄的意義。
- 當顯示的數字與你的日曆預期一致後，使用「儲存今日快照」將當地日期鎖定為一筆具日期的紀錄。日後再次開啟本頁時，每當你想要新增一筆具日期的紀錄，就再儲存一次快照。
- 若你想要瀏覽器以外的檔案，可以直接從本頁匯出 PNG（不含自訂里程碑名稱或網址的 1080 x 1350 摘要）或 CSV（包含快照日期、起始日期、自從天數欄位）。
何時該清除本地紀錄、何時該保留快照
快照隸屬於單一起始日期。工具會要求你在替換已有快照的起始日期之前先清除本地紀錄，因為每筆已儲存紀錄的意義只與當初配對的日期相符。當里程碑本身已經改變時，清除紀錄是正確的做法——例如你原本在追蹤專案啟動，後來才發現其實想記錄的是從不同日期起算的維護週期。在這種情況下，請先清除本地紀錄，再輸入新的里程碑名稱與起始日期。
當里程碑不變、只是想再記錄一筆具日期的數據時，保留快照才是正確做法。當里程碑從今天開始時，快照可以合法地為零，紀錄列表會保留這些零天的紀錄，避免你失去「剛剛開始」的條目。若想新增一筆紀錄卻又不打亂現有資料，請於之後的某個當地日期回來使用「儲存今日快照」；起始日期與既有紀錄會保持不動。
清除動作在瀏覽器內是不可逆的，因此若你想在重置前保留一份試算表副本，請先匯出 CSV。匯出作業採用瀏覽器內建的 canvas 與 Blob API；資料不會上傳，檔案是在你的裝置上產生的。
儲存並匯出已驗證的結果
當顯示的數字與你的日曆運算相符後，下一步就是讓結果得以長久保存。「儲存今日快照」會把你正在檢視的裝置當地日期、起始日期以及整數日數一起記錄為一筆紀錄。由於顯示結果是以裝置當地日期為基準，同一個起始日期在兩台不同的裝置上、或橫跨一趟旅行儲存時，可能會產生不同的快照日期——這是刻意設計，目的是讓每筆紀錄與讀者當時使用的本地日曆保持一致。
CSV 匯出會寫入三個欄位：快照日期、起始日期、自從天數。這足以讓試算表在不開啟瀏覽器分頁的情況下解讀每一筆紀錄。PNG 匯出則會產生一張 1080 x 1350 的圖片，內容包含當地當天的總計與近期快照；圖片中刻意省略你的里程碑名稱與任何網址，因此檔案可分享而不會洩露個人標籤。兩種檔案都是在瀏覽器內產生；里程碑名稱、起始日期與快照都不會離開裝置，也不會與個人檔案關聯。
若瀏覽器儲存空間無法使用，計算功能仍然可以運作，本頁會提示你無法保留快照。在此狀態下，如果你想讓任何紀錄在重新載入後留存，請在每次快照後立即匯出。
快速疑難排解參考表
| 症狀 | 可能原因 | 「自從計數器」中的修正方式 |
|---|---|---|
| 二月底前後結果差一天 | 閏年規則在可被 4 整除的年份（世紀年除外，除非能被 400 整除）多出 2 月 29 日 | 以 YYYY-MM-DD 格式重新輸入起始日期；依文件記載的閏年規則驗證差距 |
| 結果看起來差了一小時而非一整天 | 概念模型用的是經過小時而非曆日 | 將顯示的數字重新解讀為整個曆日，而非經過時長 |
| 欄位拒絕你所輸入的日期 | 未來日期、月份或日期超出範圍，或年份不在 1900–9999 之間 | 輸入當天或更早、介於 1900 到 9999 之間的有效 YYYY-MM-DD 日期 |
| 舊快照與新總計不一致 | 在已有快照之後才更改起始日期 | 先匯出 CSV，然後在重新輸入新起始日期前先清除本地紀錄 |
| 兩台裝置對同一起始日期顯示不同的「今天」總計 | 每筆結果皆以其快照時所採用的裝置當地日期為基準 | 將每台裝置的快照紀錄視為隸屬於各自的當地日期 |
用一個完整範例驗證修正結果
以一個已知的邊界日期交叉比對規則，是確認工具如文件所述運作的最快方式。以起始日期 2024-02-28（閏年，可被四整除且非世紀年）為例，並於裝置當地日期 2024-03-01 讀取結果。引擎會將兩個日期轉換為 UTC 午夜時間戳並扣減：
公式：分別計算每個日期的 (Date.UTC(year, month − 1, day) / 86400000)，再相減。
代入：(Date.UTC(2024, 2, 1) / 86400000) − (Date.UTC(2024, 1, 28) / 86400000) = (N + 2) − N
結果：2 天
對非閏年的 2023-02-28 → 2023-03-01 套用相同運算會得到 1，因為 2023 不能被四整除。如果你的本地版本對 2024 邊界讀到 2、對 2023 邊界讀到 1，表示計數器運作正常，原本「錯誤」的感覺是日曆與經過時間的認知落差，而非計算錯誤。
若你在比較不同方案，iPhone 用 Safari 計算按鍵次數：按鍵計數器對此有詳細說明。