在前面的文章中,介紹了電腦世界的大碼錶- 毫秒時間戳 (Timestamp) 。
雖然「毫秒時間戳」對電腦來說運算極快,但人眼很難馬上看出它代表哪一年哪一天;而且如果直接傳送本地時間的文字(例如 "2026/09/30 08:30"),又容易因為沒有標示時區而出錯。
為了讓「人類看得懂」且同時「電腦處理起來不出錯」,可以使用 JavaScript 原生方法的 toISOString() 。
toISOString() 是 JavaScript Date 物件的方法。
也可以把它想像成一個 「國際標準時間翻譯機」 。把時間丟進這台機器,它就會幫你翻譯成人類看得懂的國際通用時間格式。
dateObject.toISOString()
呼叫對象:必須是一個有效的 Date 物件。
回傳值:長度為 24 個字元的標準字串(例如:"2026-09-30T00:28:07.000Z")。
拿 "2026-09-30T00:28:07.000Z" 這個字串來說,每個部分都有明確的意義:
2026-09-30:人類一秒就看得懂的年-月-日。
T:用來分隔「日期」與「時間」的字母 T(Time)。
00:28:07.000:精準到毫秒的時 : 分 : 秒 . 毫秒。
Z:代表 Zero UTC Offset(即 UTC+0 世界標準時間,格林威治時間)。
使用 toISOString() 時需要注意的是:無論你的電腦位於哪個時區,產生的 ISO 字串都會自動扣除或加上時差,換算成 世界標準時間(UTC+0)。
// 假設台灣時間為 2026 年 9 月 30 日 早上 08:28:07
const now = new Date();
console.log(now.toString());
// 本地時間:"Wed Sep 30 2026 08:28:07 GMT+0800
console.log(now.toISOString());
// 換算為 UTC+0 時間:"2026-09-30T00:28:07.000Z"
在實際開發中,後端工程師或 API 文件經常會要求前端提供 ISO 格式字串,主要有以下三個實戰情境:
假設你在台灣(UTC+8)幫朋友預訂一張東京(UTC+9)飯店的房間。如果傳送未標示時區的文字 "2026-10-01 14:00",伺服器(假設架在美國 UTC-7)會搞不懂這到底是指哪裡的時間。
const bookingData = {
roomId: "ROOM_888",
checkInTime: new Date("2026-10-01 14:00:00").toISOString()
// 傳給後端的字串:"2026-10-01T06:00:00.000Z"
};
後端收到帶有 Z(UTC+0)的字串後,就能精準知道這是全世界同一個時間點。日本飯店後台打開這筆訂單時,系統就能自動加上 9 小時,正確顯示日本當地時間(2026-10-01 15:00:00)。
許多現代的資料庫工具(例如 Node.js 的 Prisma ORM、MongoDB 的 Mongoose),其預設的時間欄位型態(DateTime)原生對接的就是 ISO 8601 格式。
如果使用toISOString(),後端工程師不需要特別寫 code 將字串拆解成年月日,資料庫工具能直接把這串 ISO 字串寫入欄位中,大幅降低開發與出錯成本。
當系統發生爭議(例如:搶票系統、限時快閃活動)需要排查資料時,工程師可以直接看資料庫或 Log 檔案,比起看一串純數字(毫秒時間戳)要直覺得多。
範例:電商優惠券系統驗證領取時間
{
"couponId": "MID_AUTUMN_2026",
"claimedAt": "2026-09-30T00:32:00.123Z" // 兼具人眼可讀性與毫秒精準度
}
toISOString() 與 Date.now() 優點和適合的情境傳送格式 | 範例 | 優點 | 適合情境
------------- | -------------
ISO 字串 (toISOString()) | "2026-09-30T00:32:00.000Z" | 人看得懂又有世界統一時區,現代資料庫常用 | 現代 REST API、表單提交、跨國系統、資料庫寫入
毫秒時間戳 (Date.now()) | 1790685120000 | 體積小、效能高、純數字比大小極快。 | 網頁計時器、即時通訊 (WebSocket)、純前端計算時差