冷門日期函式：DAYS、DAYS360、YEARFRAC 與 EPOCHTODATE

日期相減用 - 就能得到天數，那為什麼還有 DAYS、DAYS360、YEARFRAC？因為在算利息、年資、API 回傳的時間戳記這幾種狀況，單純相減不太夠用。今天把這四個比較冷門的日期函式放在一起：DAYS、DAYS360、YEARFRAC 和 EPOCHTODATE。

坦白說，我在工作上用到的只有 EPOCHTODATE（資料裡有時間戳記的時候），DAYS360 跟 YEARFRAC 屬於遇到財務、貸款類的資料才會碰到，這篇當工具書放著，需要的時候回來查。

日期序號、DATE、日期相減的基礎在 日期與時間入門，年資用的 DATEDIF 在 年資、工作日、到期日，這邊不重講。

怎麼選

天數

DAYS

DAYS 回傳兩個日期之間的天數。

語法：=DAYS(結束日, 開始日)

• 結束日：比較晚的那個日期。
• 開始日：比較早的那個日期。

要注意，順序是結束日在前、開始日在後，跟 DATEDIF（開始日在前）相反，很容易記反。

先手算：10 月剩 20 天，加 11 月 30 天、12 月 31 天，20 + 30 + 31 = 81，你應該會得到 81！這個結果跟直接寫 DATE(2026,12,31) - DATE(2026,10,11) 是一樣的。

兩個參數放反的話，結果會變成負數：

結果是 -81。我個人還是比較習慣直接用減法，不過 DAYS 的好處是公式一看就知道在算天數，不用猜減號兩邊是日期還是數字。

DAYS360

DAYS360 用「一年 360 天、每個月 30 天」的算法，回傳兩個日期之間的天數。

語法：=DAYS360(開始日, 結束日, [方法])

• 開始日：起始日期。
• 結束日：結束日期。
• 方法：選填。FALSE（預設）是美國算法，TRUE 是歐洲算法，差別在月末調整規則，也包含二月最後一天，不只 31 號。

這個函式的開始日在前，跟 DAYS 相反。

先看一個平常的例子，從 2026/01/15 到 2026/10/11。每個月都算 30 天，1/15 到 10/15 是 9 個月，9 x 30 = 270 天，再扣掉 15 號到 11 號的 4 天，得到 266：

結果是 266。實際天數用 DAYS 算是 269，差了 3 天，這就是 360 天算法的特色。

先看結束日是 31 號的差別。從 2026/01/15 到 2026/03/31：

結果是 76，因為開始日小於 30 號，31 號就照 31 算。

結果是 75，歐洲算法會把 31 號一律當成 30 號。

開始日是二月最後一天也會不同。官方規則說美國法會調整月末開始日；歐洲法則把 31 日調成 30 日。對照如下：

平年與閏年的二月都能讓結果出現差異。實務上依合約或對方要求選方法，沒有說明時先確認規則，不要把預設值當成適用所有計息制度的標準。

年數

YEARFRAC

YEARFRAC 回傳兩個日期之間的年數，含小數部分。

語法：=YEARFRAC(開始日, 結束日, [天數基準])

• 開始日：起始日期。
• 結束日：結束日期。
• 天數基準：選填，用哪種方式數天數和一年的長度，0 到 4，預設是 0。

五種基準的差異，用 2026/01/15 到 2026/10/11（2026 年不是閏年）和 2024/01/15 到 2024/10/11（2024 年是閏年）來看：

手算 2026 年那一欄：實際天數是 269，30/360 的天數是 266。基準 0 是 266 / 360 = 0.7389，基準 1 是 269 / 365 = 0.7370，基準 2 是 269 / 360 = 0.7472。2024 年是閏年，實際天數多一天變成 270，基準 1 除以 366 得到 0.7377，基準 3 還是除以 365，得到 0.7397。

結果是 0.738888889，上面的表格和後面的數字我都取到 4 位。換成實際天數基準：

結果是 0.736986301，也就是 0.7370。

拿來算年資也行，例如到職日 2019/03/18 到 2026/10/11，預設基準是 7.5639 年，如果改用基準 3（實際天數 / 365）是 7.5726 年。算出來的小數年跟 DATEDIF 的整年、整月不同，兩者要放在報表上的話，先說明用哪種算法。

基準 1 橫跨多年時的算法本文不涵蓋，這篇的例子都限定在同一年內。

時間戳記

EPOCHTODATE

EPOCHTODATE 把 Unix 紀元時間戳記（從 1970/01/01 00:00:00 UTC 起算的秒數）轉成日期時間。

語法：=EPOCHTODATE(時間戳記, [單位])

• 時間戳記：數字，從 1970/01/01 00:00:00 UTC 起算的數量。
• 單位：選填。1 是秒（預設），2 是毫秒，3 是微秒。

來源是 API、日誌或資料庫匯出的資料，常常是 1700000000 這種十位數字。十位數是秒，十三位數通常是毫秒，十六位數是微秒。

先手算：1700000000 秒除以 86400 約 19675.926 天，1970/01/01 加上 19675 天是 2023/11/14，剩下 0.926 天是 22:13:20。所以結果是 2023/11/14 22:13:20。這裡的 TEXT 只是為了把格式固定下來，單用 =EPOCHTODATE(1700000000) 儲存格也會顯示日期時間。

同一個時刻，毫秒版本是 13 位數，要指定單位 2：

結果一樣是 2023/11/14 22:13:20。單位選錯會差 1000 倍，如果轉出來的日期離譜，先數一下時間戳記幾位數。

EPOCHTODATE 的結果是世界標準時間，不是台灣時間。台灣是 UTC+8，加 8 小時就好：

結果是 2023/11/15 06:13:20，日期也跨到隔天了。

反過來，日期轉成時間戳記沒有專用函式，用日期序號算就好。1970/01/01 的序號是 25569，所以：

先手算：46306 - 25569 = 20737 天，乘 86400，得到 1791676800。

匯入 API 資料時，記得先確認是秒還是毫秒，再套 EPOCHTODATE 吧！

我是喜特先生，Mr. Sheet，我們下個教學見！