# 7月份資料解析異常問題報告

## 問題描述
使用者回報 7 月份的加班計算結果不正確，具體表現為：
1.  **時間偏移**：出現如 `17:23`、`18:23` 等帶有 `23` 分鐘尾數的異常時間。
2.  **下班時間不符**：例如 7/4 使用者預期下班時間為 `19:00`，但系統計算出 `18:23` 或 `18:53`。

## 原始資料分析 (以 7/4 為例)
讀取 `2025年7月` 工作表的原始資料 (Raw Data) 發現數據本身存在**矛盾**：

| 欄位 | 值 (Raw Value) | 解析意義 |
| :--- | :--- | :--- |
| **B (日期)** | `2025-07-04 五` | 日期為 7/4 |
| **D (上班打卡)** | `0.375` | `09:00:00` (0.375 * 24h) |
| **E (下班打卡)** | `0.7708333333333334` | `18:30:00` (0.770833 * 24h) |
| **F (工作時數)** | `9.5` | 9.5 小時 |
| **G (午晚休)** | `1` | 1 小時 |

### 矛盾點
1.  **打卡時間 vs 工時欄位**：
    *   依據 **D (上班)** 與 **E (下班)** 計算：`18:30` - `09:00` = 9.5 小時。扣除 G (休息 1h) = **8.5 小時** 實際工時。
    *   依據 **F (工作時數)** 欄位：數值為 **9.5 小時**。若此為實際工時，則加上休息 1h，總工時應為 10.5h。推算下班時間應為 `09:00` + 10.5h = **19:30**。
    *   **結論**：欄位 E (`18:30`) 與 欄位 F (`9.5`) 的數據不一致。目前的程式邏輯是**優先信任打卡時間 (D, E)** 進行重算，因此得出 `18:30` 下班，工時 8.5h。若使用者認為應為 `19:00` 或 `19:30`，則代表原始資料的 E 欄位可能是錯誤的，或者 F 欄位才是正確依據。

2.  **23分鐘的偏移 (17:23 / 18:23)**：
    *   在 Google Apps Script 環境中，直接使用 `new Date('2025-07-04')` 建立日期物件時，可能會因為執行環境的時區設定 (如 UTC vs Local) 導致基準時間產生偏移（例如變成前一天的 23:00 或當天的 00:23）。
    *   加上時間分數 (0.375) 後，這個偏移量會被帶入最終結果，導致出現 `XX:23` 的異常分鐘數。

## 已嘗試的修正
1.  **針對 23 分鐘偏移**：
    *   修改 `parseMonthlyFormat7Plus` 函式，不再依賴 `new Date(字串)` 自動解析。
    *   改為手動解析 `YYYY-MM-DD` 字串，並使用 `new Date(y, m, d)` 明確建立本地時間的 00:00:00 基準點，再疊加時間分數。
    *   理論上應能消除時區造成的 `23` 分鐘誤差。

2.  **針對 7 月特殊格式**：
    *   增加了對「小數點時間格式」(Time Fraction) 的支援，與 Excel Serial Date (4xxxx) 區分處理。

## 待解決事項
1.  **確認數據信任來源**：
    *   需要使用者確認：當 E 欄 (下班打卡) 與 F 欄 (工作時數) 衝突時，應以哪個為準？
    *   若以 F 欄為準，則需修改邏輯：`下班時間 = 上班時間 + 休息時間 + F欄工時`。
2.  **環境時區確認**：
    *   若手動建立日期物件後仍有偏移，可能需要檢查 Google Apps Script 專案的 `appsscript.json` 時區設定 (`timeZone`) 是否正確設定為 `Asia/Taipei`。

## 建議下一步
*   檢查 `appsscript.json` 的時區設定。
*   與使用者確認 7/4 的實際下班時間到底是 `18:30` (E欄)、`19:30` (F欄推算) 還是 `19:00` (使用者口述)？這將決定計算邏輯的修正方向。