「自從 天數 計算機」計算的是從指定的起始日期到今天本地日期之間的完整格里高利曆天數,而不是從某個時鐘時間戳記起算的 24 小時時段。本工具運作於日期元件而非小時數,因此它回答的是自某個里程碑開始以來已經過了多少個日期,這與掛曆的計算方式相同。在內部,所選的起始日期與裝置目前的本地日期都會各自轉換為 UTC 午夜值,接著將整數日數相減,結果以完整的日曆天數顯示。在 UTC 午夜進行運算是刻意設計的:否則,夏令時間轉換會將本地時鐘推移一小時,讓一天的差距變成 23 小時或 25 小時的差距,在時鐘變更當天開啟本工具的使用者就會得到錯誤的結果。閏年的邊界情況依照標準的格里高利曆規則處理,因此閏年的 2 月 28 日在 3 月 1 日會正確顯示為兩天,而非閏年的 2 月 28 日在 3 月 1 日則顯示為一天。顯示的數字是日曆答案,而不是碼錶讀數。
日曆天數 vs 24 小時時段
一個日曆天是日曆上的一個日期,從一個本地午夜計算到下一個本地午夜。24 小時時段則是從特定時間戳記起以小時為單位測量的持續時間。兩種答案通常一致,但在兩個眾所周知的案例中會出現分歧:夏令時間轉換,以及跨越閏日的日期。在實施夏令時間的地區,春季往前調的星期日,本地時鐘會從大約 02:00 跳到 03:00,因此包含該夜晚的時段在時鐘上只有 23 小時,但仍然是兩個日曆日期。在秋季往後調的星期日,相同的時段在時鐘上是 25 小時,但仍然是兩個日曆日期。24 小時計算機會根據所選的夜晚將這些時段記錄為 23、24 或 25 小時,而日曆計算機每次則會記錄為一個日曆天。
「自從天數計算機」正是屬於後者的工具。它會讀取起始日期、讀取裝置目前的本地日期,然後回報介於兩者之間的完整日曆日期數量。這個結果與您在一天當中的哪個時刻開啟頁面無關,因此在同一個本地日期的 08:00 開啟與在 22:00 開啟會得到相同的數字,跨越夏令時間的界線開啟也會得到相同的數字。
| 情境 | 日曆天答案 | 24 小時答案 (依時間戳記而定) |
|---|---|---|
| 在與起始日期相同的本地日期開啟本工具 | 0 天 | 0 到不到 24 小時 |
| 在起始日期之後的下一個本地日期開啟 | 1 天 | 大約 24 小時,但在夏令時間夜晚為 23 或 25 小時 |
| 跨越春季往前調的星期日開啟 | 每個本地日期 1 天 | 若跨越夏令時間位移計算則為 23 小時 |
| 跨越秋季往後調的星期日開啟 | 每個本地日期 1 天 | 若跨越夏令時間位移計算則為 25 小時 |
| 2 月 28 日 (閏年) 至 3 月 1 日 | 2 天 | 大約 48 小時 |
| 2 月 28 日 (非閏年) 至 3 月 1 日 | 1 天 | 大約 24 小時 |
如果您的目的是要知道自某個里程碑以來已經過了多少個日期,那麼日曆天的答案就是您要的。如果您的目的是要知道自某個精確時刻起已經過了多少小時,那麼使用經過時間工具會更合適。
UTC 午夜計算的運作方式
產生日曆天數的計算過程簡短且具確定性。本工具會將每個日期讀取為年、月、日,根據該月與該年的日曆長度驗證月份,對二月套用格里高利曆的閏年規則,然後將通過驗證的元件轉換為 UTC 午夜值。接著將兩個 UTC 午夜值分別除以一天的長度 86,400,000 毫秒,再將整數日數相減。所得結果就是完整的日數。
以 UTC 午夜值相減而非以本地時鐘值相減,正是讓夏令時間得以排除在外的關鍵。UTC 沒有夏令時間轉換,因此 UTC 的一天永遠恰好是 24 小時。然而顯示結果仍會連結到裝置的本地日曆日期,因此您儲存的快照使用的是您在所在地掛曆上實際看到的日期。UTC 運算搭配本地顯示的這種組合,正是 ECMA-262 Date.UTC 規範所採用的模式,該規範定義了本工具所依賴的轉換方式。
格里高利曆的閏年規則本身就是標準規則:能被 4 整除的年份為閏年,但世紀年還必須能被 400 整除。美國海軍天文台也發布了相同的規則,並以此作為美國民用時間的參考。套用該規則正是讓二月的邊界情況在掛曆上表現如預期的原因。
閏年與日曆邊界行為
日曆天數需要一條精確的規則,「自從天數計算機」遵循格里高利曆的標準規則,以便二月與世紀年的邊界情況如您在掛曆上所預期的那樣運作。
- 閏年的二月: 2024-02-28 到 2024-03-01 回傳 2 天,因為 2024 年的二月有 29 天。
- 非閏年的二月: 2023-02-28 到 2023-03-01 回傳 1 天,因為 2023 年的二月有 28 天。
- 世紀年: 2000-02-28 到 2000-03-01 回傳 2 天,因為 2000 年能被 400 整除。1900-02-28 到 1900-03-01 回傳 1 天,因為 1900 是世紀年但不能被 400 整除。
- 同日起始: 起始日期等於今天本地日期時會回傳 0 天,這是有效的日曆結果,而非空值。
輸入欄位強制要求 1900 到 9999 之間的四位數年份,並在計算前根據月份長度檢查日期,因此像 2024-02-30 這樣的無效日期會被拒絕,而不是被默默地順延到三月。
如何使用「自從天數計算機」取得日曆天數
- 開啟「自從天數計算機」,為您要追蹤的里程碑輸入一個簡短名稱,例如專案啟動、例行變更週年、維護週期或具名的等待期間。
- 在 YYYY-MM-DD 欄位中選擇起始日期。該欄位接受 1900 到 9999 之間的完整四位數年份值,並拒絕未來的日期。今天或更早的日期皆可,包括今天本身。
- 儲存起始日期。頁面現在會顯示自該起始日期到裝置目前本地日期之間的完整格里高利曆天數。
- 讀取結果。如果起始日期就是今天,結果為零,這是真實的日曆答案,而不是缺少的計數。
- 每當您想為當下查看的本地日期留下有日期戳記的紀錄時,可使用「儲存今日快照」。每個快照會儲存在本地瀏覽器的 counter:days-since-counter 之下,零天快照會持續顯示在歷史紀錄清單中。
- 在歷史紀錄存在期間,請保持起始日期不變。若要開始一個有自己歷史紀錄的不同里程碑,請先清除本地歷史紀錄,這樣舊的快照才不會被默默地以新的起始日期重新寫入。
- 匯出 PNG 可取得可分享的 1080 x 1350 摘要,或匯出 CSV 可取得包含「Snapshot date(快照日期)」、「Start date(起始日期)」與「Days since(自從天數)」欄位的試算表。
整個流程都在您的瀏覽器內完成。沒有帳號、沒有上傳佇列,也沒有伺服器端的日期服務代您計算天數。您的里程碑名稱、起始日期與快照都存放在本地瀏覽器儲存空間中,不會被傳送到任何地方。
本工具不追蹤的事項 (以及該改用什麼)
「自從天數計算機」只回答一個特定的問題,並保持在該範疇內。它並非手動增量按鈕、不會顯示即時跳動的計數器、不會建立倒數未來事件的倒數計時、不會傳送提醒,也不會聲稱某個日期具有法律、財務、醫療或契約上的意義。它也不會解讀里程碑的含義。如果上述任何一項才是您真正的需求,那麼另一個工具會更合適。
| 如果您想… | 更好的選擇 | 原因 |
|---|---|---|
| 計算自某個具名的過去日期以來的完整日曆天數 | 自從天數計算機 | 通過驗證的格里高利曆運算、本地快照、PNG 與 CSV 匯出 |
| 以小時、分鐘與秒為單位測量實際經過的持續時間 | 線上碼錶 | 從零開始,持續執行,支援分段計時 |
| 為每次重複事件點擊增加一次計數 | 線上計次器 | 搭配每日本地歷史的手動點擊或輕觸 |
| 倒數到未來的日期或時間 | 線上倒數計時器 | 倒數到目標時間,而不是從過去的日期往上累計 |
關於同一個工具的其他常見問題,請參閱日期持續時間計算機指南以進一步了解日曆天的運算,以及未來起始日期指南以瞭解為何未來的起始日期會被拒絕,而不會被轉換為倒數計時器。
儲存與匯出日曆天快照
快照是本工具為特定本地日期保留日曆天數書面紀錄的方式。第一個快照會在您儲存起始日期時建立,您也可以在之後的造訪中,點擊「儲存今日快照」來新增更多快照。當里程碑在您儲存快照的當天開始時,快照可以是零,而零天快照會持續顯示在歷史紀錄清單中,時間軸的起點不會被隱藏。
每個快照是一列資料,包含儲存該快照的日期、所依據計算的起始日期,以及「自從天數」的值。這樣的結構讓您在數月後於試算表中開啟檔案時仍能正確解讀紀錄。
- 匯出 PNG: 產生一張 1080 x 1350 的圖片,顯示作用中本地日期的總數與最近的快照。該圖片不包含網址或您的自訂里程碑名稱,可限制可分享檔案中的個人脈絡。
- 匯出 CSV: 產生一個簡單的檔案,包含「Snapshot date(快照日期)」、「Start date(起始日期)」與「Days since(自從天數)」欄位。試算表或封存工具可解讀每一列資料,而不必依賴瀏覽器專用的標籤。
匯出作業是在瀏覽器內使用原生 canvas 與 Blob API 產生,因此沒有伺服器端的處理步驟,您的里程碑名稱或起始日期也不會被上傳。如果瀏覽器儲存空間無法使用,顯示的計算仍然有效,頁面會告訴您快照無法被保留;計數本身不會受到其他影響。清除本網站的瀏覽器資料會移除紀錄,而在第二個瀏覽器中開始時,計算機會是空的。