🕰時間戳解析異常怎麼查？14/12/10/8 位格式一次搞懂，並釐清最後寫進哪張資料表（FT_LOT_INFO / FT_TEST

🕰時間戳解析異常怎麼查？14/12/10/8 位格式一次搞懂，並釐清最後寫進哪張資料表（FT_LOT_INFO / FT_TEST_INFO / SYSEVENT）

- 1月 11, 2026

為什麼「時間戳」會害整批資料匯入失敗？

在很多資料匯入（ETL / Loader）系統裡，「時間戳（timestamp）」是最常見、也最容易踩雷的欄位之一。

原因很簡單：
系統通常用一段規則把「一串數字」當作日期時間來解讀，例如：

20250108010317 代表 2025/01/08 01:03:17
250108010317 代表 2025/01/08 01:03:17（只用兩位數年份）

只要其中的「月份/日期」不合理（例如 3 月 71 日），解析就會失敗，接著可能造成：

這筆資料被判定為異常、跳過
甚至整個檔案/整批匯入流程被中斷
最後資料庫的時間欄位會是空值或錯值，影響報表與追查

這篇文章會用「完全不懂也看得懂」的方式，帶你掌握：

系統支援哪些時間戳格式
異常時間戳長怎樣、為何系統不吃
這些時間到底存進資料庫哪裡（FT_LOT_INFO / FT_TEST_INFO / SYSEVENT）
第一時間排查與改善方向

系統支援的時間戳格式（最常見 4 種）

以下是系統「明確支援」的四種純數字時間戳（你只要記住：位數不同，代表資訊量不同）：

✅ 14 位：YYYYMMDDHHmmSS

格式：年(4) 月(2) 日(2) 時(2) 分(2) 秒(2)
範例：20250108010317
解讀：2025/01/08 01:03:17

✅ 12 位：YYMMDDHHmmSS

格式：年(2) 月(2) 日(2) 時(2) 分(2) 秒(2)
範例：250108010317
解讀：2025/01/08 01:03:17（通常 25 → 2025）

✅ 10 位：YYYYMMDDhh

格式：年(4) 月(2) 日(2) 時(2)
範例：2025010801
解讀：2025/01/08 01:00:00（分鐘秒數預設為 00）

✅ 8 位：YYYYMMDD

格式：年(4) 月(2) 日(2)
範例：20250108
解讀：2025/01/08 00:00:00（時間預設為 00:00:00）

小提醒：位數越短，系統會用「預設值」補齊時分秒，這在報表排序或跨日統計時要特別留意。

異常時間戳的兩種典型特徵（為何系統解析會爆）

你這次遇到的異常，核心不是「長得像數字」，而是「長得像日期，但其實不是合法日期」或「系統根本沒支援這種邏輯」。

❌ 異常 1：12 位但日期不合法

範例：250371000300

前 2 位：25（年）
第 3–4 位：03（月）✅
第 5–6 位：71（日）❌（3 月不可能有 71 日）

這種情況系統通常會發生：

先「以為它是合法的 12 位格式」
接著嘗試轉成日期
轉換時因為日期不合法而失敗（等同「解析錯誤」）

結果通常是：

該筆資料的時間欄位變成空
或整筆被判定匯入失敗（視系統容錯而定）

❌ 異常 2：13 位格式（系統目前不支援）

範例：2508229010800

你推測得很合理：它可能是
YYMM + DDD（年中第幾天） + HHmmSS 的組合。

例如：

YYMM：25 08（2025 年 8 月）
DDD：229（第 229 天）
HHmmSS：010800（01:08:00）

但重點是：
目前系統只認 14/12/10/8 位等格式，並沒有「13 位＋DDD」這種規則。

所以系統會：

完全無法對應解析規則
最終只能當作「不認得的字串」
轉換結果通常是空值（None/null），後續寫入就會缺時間

解析後的時間會存到哪個 SQL 資料表？

很多人以為「時間戳在檔名出錯」只是檔名問題，但其實最終影響的是：資料庫欄位的時間會不完整，直接影響查詢、報表、對帳、追溯。

依你目前流程，時間戳會落到三個重點位置：

1) FT_LOT_INFO：Lot 層級的開始/結束時間

典型欄位概念：
- ST_TIME：開始時間
- END_TIME：結束時間

用途：用來表示「這一批（Lot）」的作業起訖時間。

2) FT_TEST_INFO：Test 層級的開始/結束時間

典型欄位概念：
- ST_TIME：開始時間
- END_TIME：結束時間

用途：用來表示「某次測試」的作業起訖時間。
通常 Test 明細會比 Lot 更細，Lot 的 END_TIME 有時也會由多筆 Test 的時間彙整回填。

3) SYSEVENT：系統執行紀錄時間（不是檔名時間戳）

這張表記錄的是「系統何時執行匯入/處理」，常見欄位概念：

EXECUTION_TIME：執行時間（由資料庫系統時間產生）

用途：追查「這次匯入是何時跑的、誰跑的、哪個檔案被處理」。

重要釐清：

FT_LOT_INFO / FT_TEST_INFO 的時間，屬於「資料本身的時間」
SYSEVENT 的時間，屬於「系統處理的時間」
兩者常常會被搞混，但排查問題時需要一起看。

用最白話方式理解：系統怎麼把時間戳變成日期？

你可以把它想成「收銀機讀條碼」：

系統先看「位數」判斷是哪一種格式
再用對應規則拆解成年/月/日/時/分/秒
只要拆出來的年月日不成立，就整筆變成「無法解析」

下面是示意 pseudocode（刻意改成泛用寫法，避免任何專案機密）：


function parseTimestamp(text):
  if text matches 14 digits:
    return parse as YYYYMMDDHHmmSS
  else if text matches 12 digits:
    return parse as YYMMDDHHmmSS
  else if text matches 10 digits:
    return parse as YYYYMMDDHH
  else if text matches 8 digits:
    return parse as YYYYMMDD
  else:
    return null  // 系統不支援

而你的異常就是：

12 位：雖然匹配成功，但「日期內容不合理」→ 解析失敗
13 位：根本不在支援列表 → 直接回傳 null

排查步驟：遇到「時間戳截取異常」先做這 5 件事

1) 先確認「原始字串」是從哪裡來

來自檔名？
來自 Excel 欄位？
來自某段拼接（例如 YYMM + DDD + time）？

來源不同，修法就不同。

2) 把異常值分類（12 位不合法 vs 13 位不支援）

12 位但日期爆掉：通常是資料本身錯、或欄位位移/截取位置錯
13 位：通常是規格變動（供應商改規則）但系統未跟上

3) 檢查「月/日」與「位數」是否合理

你已經抓到重點：
12 位的第 5–6 位必須是 01–31（並依月份限制），否則一定會炸。

4) 追查最終是否寫入 FT_LOT_INFO / FT_TEST_INFO 的 ST_TIME/END_TIME

你可以用資料庫查詢確認：

是否出現大量 null
是否同批資料的 Lot 有時間但 Test 沒有（或反過來）

5) SYSEVENT 的 EXECUTION_TIME 用來對照「問題是資料本身」還是「那次匯入流程」

如果同一個檔案在不同時間跑、結果不同，問題可能是：

當次匯入規則、版本、或前處理流程不同

改善方向：要不要支援 13 位（YYMM+DDD+HHmmSS）？

如果供應商已經穩定改成 13 位（YYMM + DDD + HHmmSS），那通常建議：

先加「前置偵測」：看到 13 位就不要走原本解析
新增解析規則（DDD 轉日期）
同時加上「資料合理性檢查」：例如 DDD 必須 001–366

示意 pseudocode：


if length(text) == 13 and looksLike(YYMM + DDD + HHmmSS):
  date = convertDayOfYearToDate(YY, DDD)
  time = parse(HHmmSS)
  return combine(date, time)

注意：這種新增規則一定要寫清楚「YYMM 與 DDD 的關係」是否固定，否則可能解析出錯又更難追。

結語：時間戳問題其實是「規格同步」問題

這次你遇到的狀況，本質上不是工程師粗心，而是常見的系統現實：

外部資料格式（供應商、檔名規則、Excel 欄位）變了
系統的「解析規則」沒同步更新
最終造成 SQL 表中的時間欄位缺失或匯入失敗

只要你掌握這篇文章提到的三件事：

系統支援哪些位數與格式
異常值的分類方式（不合法 vs 不支援）
解析後落在哪些資料表欄位（FT_LOT_INFO / FT_TEST_INFO / SYSEVENT）

你就能很快定位問題落點，跟供應商/同事討論也更有依據。

搜尋此網誌

小小大大學