設定 cache 的存活時間要填秒、寫進度報告要講天、估算訂閱長度要用月，而這些數字之間的換算（86400、604800、2592000）沒有人記得住。這個工具在毫秒、秒、分鐘、小時、天、週、月、年之間互換，基準是秒。要先講清楚的是：這裡的**月固定當成 30 天、年固定當成 365 天**，那是估算慣例而不是曆法，所有和「哪一天」有關的問題它都答不了。換算在瀏覽器裡完成，你填的數字不會被送出；頁面本身則和站上其他頁一樣需要載入廣告等第三方資源。
使用步驟
- 「輸入數值」欄位填數字，預設是 1。小數可以直接填，例如 0.5 天。
- 「來源單位」下拉選單有八個選項，從年到毫秒，預設停在秒。選的是你手上那個數字的單位。
- 結果網格一次列出其餘七個單位，各附一顆複製按鈕。要把 30 天換成秒，選天、填 30，秒的卡片就顯示 2592000。
- 要反查也一樣：填 604800 選秒，天的卡片會顯示 7。輸入框的內容在切換單位時不會被清掉。
- 欄位空白時所有卡片顯示破折號，此時複製到的是空字串。
什麼時候用得上
算出設定檔要填的秒數
HTTP 的 Cache-Control: max-age、cookie 的 Max-Age、JWT 的有效期、Redis 的 EXPIRE 幾乎全部以秒為單位。一週是 604800、三十天是 2592000、一小時是 3600。想清楚要放多久，換成秒直接複製進設定檔即可。
把長時間任務的耗時講成人話
一個跑批花了 100000000 毫秒、模型訓練跑了 500000 秒，貼進來就知道那分別是 1.157407407 天與 5.787037037 天。寫進報告時用天或小時，比一長串毫秒有說服力得多。
推算 SLA 允許的停機時間
可用度承諾用的正是 365 天一年的算法，所以這個工具剛好合用：99.9% 代表一年可停 0.001 年，填 0.001 選年，小時的卡片顯示 8.76；99.99% 就填 0.0001，得到 0.876 小時，也就是 52.56 分鐘。
粗估訂閱、租約與專案期程
18 個月的合約是 1.479452055 年、6 個月是 180 天。這類「大概多久」的溝通用固定月長就夠了；一旦要寫進契約的到期日，就得改用真正的日曆計算。
限制與注意事項
- **月一律是 30 天、年一律是 365 天。** 這是估算用的慣例，不是任何一種曆法：現實中的月有 28 到 31 天，四年會有一次 366 天的年。直接後果是這張表內部並不自洽——1 年換成月會得到 **12.16666667**，而 12 個月換成年只有 **0.9863013699**，來回換一次回不到原點。看到這兩個數字不要以為是 bug，那是 365 ÷ 30 與 360 ÷ 365 的結果。
- 同樣地，1 年是 52.14285714 週而不是 52 週，1 個月是 4.285714286 週。週的 7 天倒是沒有爭議，問題永遠出在月和年身上。
- 它不處理任何和日期有關的事：閏年、大小月、時區、日光節約時間、季末結算日全都不在範圍內。「三個月後是哪一天」「這兩個日期之間差幾天」這類問題請改用開發工具裡的時間戳轉換，那個工具處理的是真正的時刻。
- 最小單位是毫秒。微秒與奈秒不在表內，效能分析與硬體時序常用的 µs、ns 請自己先除以 1000 或 1000000 再填毫秒。另一端也沒有十年、世紀，那些自己乘就好。
- 這不是時長字串的解析器。輸入框只收單一數字，
01:30:00、1h30m、90 分鐘這些寫法都不會被接受，請先自己拆成數字與單位兩部分。 - 很小的結果會用科學記號印出來：1 毫秒換成年顯示為
3.170979e-11，因為它小於 10⁻¹⁰；1 秒換成年則是3.170979198e-8。這是格式門檻，不是精度不足。
常見問題
為什麼 1 年換成月是 12.16666667，不是 12？
因為兩個單位是各自獨立定義的，不是從彼此推導出來的。年被定成 365 天、月被定成 30 天，而 365 ÷ 30 = 12.1666…，並不等於 12。反過來 12 個月只有 360 天，換成年就是 0.9863013699。真正的曆法裡一年平均有 12 個月、每月平均 30.44 天，但只要把「月 = 30 天」寫死，這個內部矛盾就一定存在，任何用固定月長的工具都一樣。實務上的建議：需要跨越月與年這兩級的估算，先統一換成天再算，就不會被這個誤差追著跑。
合約寫「三個月」，我可以用這裡算出來的 90 天嗎？
算感覺可以，寫進契約不行。這裡的 3 個月剛好是 90 天，但實際的三個月是 89 到 92 天，取決於從哪一天起算：從 1 月 1 日算起是 90 天（平年），從 3 月 1 日算起是 92 天，差了兩天。法律文件裡的「三個月」通常指到第三個月的同一日，遇到 1 月 31 日這種日子還有各自的處理規則。要精確的到期日，請用真正的日曆或時間戳轉換工具，不要用固定 30 天推算。
有微秒和奈秒嗎？我在看效能分析的資料。
沒有，最細只到毫秒。Profiler、trace 系統、硬體規格常用 µs（微秒，千分之一毫秒）與 ns（奈秒，百萬分之一毫秒），要換的話自己先除：1500 µs 就是 1.5 毫秒，250 ns 就是 0.00025 毫秒。順帶一提，微秒等級的 timestamp（Postgres 與部分 tracing 系統的預設精度）也常被誤當成毫秒，那是另一個經典的千倍誤差來源。
cookie 或 token 想設定「30 天」，秒數要填多少？
2592000。填 30、選天，秒的卡片就是這個數字。常用的還有：一小時 3600、一天 86400、一週 604800、一年 31536000。這些設定值本來就是以固定天數在算的（Max-Age 的定義就是「從現在起經過幾秒」），所以用這個工具算出來的秒數可以直接用，不會有曆法問題。真正要小心的是別和 Expires 搞混——那個要的是一個絕對時間點，不是秒數。
可以直接貼 `01:30:00` 或 `1h30m` 嗎？
不行，輸入框只收一個數字。01:30:00 請自己讀成 1.5 小時或 90 分鐘再填；1h30m 同理。這個限制來自輸入框本身是數字型別，帶冒號或字母的字串根本填不進去。如果你要處理的是一整批時長字串（例如字幕檔或通話紀錄的匯出），那已經是文字處理而不是單位換算的問題，用試算表的分欄功能會快得多。