日期安排

時間戳差八小時，先查單位和時區再改資料

用台北 2026-01-01 00:00 的固定時刻，對照 UTC、Unix 秒與毫秒。先分清顯示時區和原始數值，再用一筆資料往返核對，避免重複加八小時或乘 1000。

SNYR 工具箱更新於 2026/10/22

日期顯示在前一天，原始時間可能沒錯

時間戳顯示差八小時，先保留原值，查清楚欄位單位和顯示時區。我不會直接加八小時，因為那可能把原本正確的事件時間改錯。時區決定鐘面和日期怎麼顯示，日期看起來往前一天，不表示事件真的提早發生。

例如社區報名通知寫 2026 年 1 月 1 日凌晨 0 點，匯出紀錄卻是 2025 年 12 月 31 日 16 點。如果通知採台北時間、紀錄採 UTC，這兩個寫法可以指同一時刻，只是跨過了顯示日期。

先看欄位說明，必要時詢問資料提供者。匯出的試算表可能已做過轉換，畫面和原始數值不是同一層，不能只憑看起來像哪一天就猜。

固定用台北 2026-01-01 00:00:00 核對：它就是 UTC 的 2025-12-31T16:00:00Z，Unix 秒數為 1767196800，毫秒數為 1767196800000。數值差一千倍，是單位不同，事件時間相同。

字串末尾的 Z 表示 UTC；2026-01-01T00:00:00+08:00 則寫出 +08:00 偏移，兩者都能確定同一時刻。如果只交付 2026-01-01 00:00，收件端還需要知道該用哪個時區。

看到十三位，就一定是毫秒嗎？十位、十三位只能當線索，不是單位規則，不同年代或時間編碼可能有不同位數。我會以欄位約定為準：明確要求毫秒，才把秒數乘 1000；要求秒，則按需要的精度處理毫秒。

欄位未完整顯示時，可左右捲動表格。

本例在指定日期使用台北時區，所以是 UTC+8。其他地區的偏移可能受夏令時間與歷史規則影響。同一城市今天的偏移，也不能直接套到所有過去或未來日期。

如果是跨國線上活動，我會提供含時區的完整時刻，再附主要參加者的當地時間。只寫「晚上八點」，轉傳後很容易不知道是哪裡的八點。這時補上日期與時區，比多寫幾位秒數更能幫人準時參加。

比較兩筆事件先後，要先轉成共同的絕對時刻。格式化後的文字若用不同日期格式或時區，按字典順序排序未必就是時間先後。

生日、活動日期、帳務月份，有時只是在記日曆資訊，不代表某一瞬間。生日 2000-05-03 若硬套 UTC 午夜，再轉到另一地區，可能變成前一天，反而改掉要保存的生日。

所以格式要按欄位用途選。登入紀錄需要完整時刻，生日通常保留年月日，會議開始時間則要日期、時刻和時區。我會先問這欄記的是「哪一天」，還是「哪一瞬間」，再決定怎麼轉，不因它們都有日期就套用同一段程式。

JavaScript 對只有日期、以及不含時區的日期時間字串，採不同解析規則。自己寫匯入流程時，用明確格式並測試，不讓瀏覽器猜任意文字。本站轉換工具接受的格式與限制，另見工具頁說明。

先用本例或另一筆已知時刻做往返核對：把原值轉成人可讀時間，再用明確時區轉回數值，看是否回到同一值。多乘一次 1000、重複加八小時，通常在這一步就能發現。

我會把原始欄位、單位、來源時區、預期顯示與實際結果一起留下。轉不回原值，就先查哪項條件不同，暫時不覆寫整批資料。尤其這份紀錄若已用來排報名順序，更要保留可回復的原始檔，避免修顯示時連先後順序也改掉。

交付時可寫「此欄為 Unix 毫秒；通知頁依 Asia/Taipei 顯示」。比只寫 timestamp 更清楚，接手的人才能知道要保留哪個事件時刻、用什麼時區顯示。先把這兩件事說清楚，就不必靠猜測再加一次八小時。