神秘的13位數

在寫 JavaScript 或是串接 API 資料時，你可能看過長成這樣的資料：

{
  "orderId": "A123456",
  "createdTime": 1790685000000
}

這個 1790685000000 既不像日期，也不像時間，看起來像某種密碼。

其實，這就是程式開發中最常被拿來處理時間的工具——毫秒時間戳（Timestamp）。

筆記目錄

• 電腦世界裡的「超大碼錶」
  • 時間戳（Timestamp）是什麼？
• 為什麼是 1970 年？
• 為什麼不直接用「2026/09/29」就好？
  • 1. 克服「時區障礙」
  • 2. 純數字比大小，速度飛快
• 在 JavaScript 中如何操作時間戳？
  • 1. 抓取「現在這一刻」的時間戳
  • 2. 時間戳與「日期」互相轉換
• 總結

電腦世界裡的「超大碼錶」

想像全世界的電腦在 1970 年 1 月 1 日的半夜 00:00:00 那一刻，一起按下了一支超巨大的「碼錶」。

這支碼錶從按下那一秒開始，就以 1 秒跳 1000 下（ 1 秒 = 1000 毫秒） 的速度，一刻不停地一直跑、一直跑，跑到了今天。

時間戳（Timestamp） 是什麼？

當我們在程式裡抓取時間戳時，就像是：抬頭瞄了一眼那支碼錶，看看它「從按下開始到現在，總共跳了幾毫秒」。

時間戳 1790685000000，就代表那支碼錶已經跳了 1,790,685,000,000 毫秒。

為什麼是 1970 年？

這個起點在電腦科學裡被稱為 Unix 紀元（Unix Epoch）。

因為在 1960 年代末到 1970 年代初，正是現代作業系統（Unix）剛被發明出來的時候。當時的工程師們需要統一一個標準時間起點來讓所有電腦對時，於是就選了 1970 年 1 月 1 日 00:00:00 UTC 當作電腦世界的「誕生元年」。

為什麼不直接用「2026/09/29」就好？

人類習慣看 2026-09-29 21:30 這種有年、月、日、時、分格式的文字，但對電腦來說，純數字的時間戳卻比較好用。原因主要有兩個：

1. 克服「時區障礙」

當我們在台灣的早上 9 點發送一則貼文，美國的朋友在當地時間的晚上 9 點看到。

• 如果儲存文字 2026-09-29 09:00：資料庫會搞不清楚這到底是指台灣時間還是美國時間，容易產生嚴重的時間錯亂。

• 如果儲存時間戳 1790685000000：這串數字代表的是「碼錶走過的絕對時間」。全世界的電腦拿到這串數字後，只要根據使用者當地的時區自動轉換，就能精準顯示出正確的當地時間。

2. 純數字比大小，速度飛快

假設我們要寫一個「判斷優惠券是否過期」的功能：

• 文字比較：電腦要把 2026/09/29 拆開成字串，比對年份、月份、日期，還要處理閏年跟大小月，非常繁瑣。

• 時間戳比較：電腦只需要比對 當前時間戳 > 截止時間戳。對電腦來說，比較兩個純數字的大小，不用一秒就都比完了。

在 JavaScript 中如何操作時間戳？

在前端開發中，我們最常用到的時間戳操作有兩種：

1. 抓取「現在這一刻」的時間戳

如果只需要拿到當下的時間戳做計算或防快取，直接使用 Date.now() 是最快、效能最好的方式：

// 取得當下的毫秒時間戳
const nowTimestamp = Date.now();

console.log(nowTimestamp); // 印出如：1790685000000

2. 時間戳與「日期」互相轉換

• 把特定日期轉成時間戳：

const christmas = new Date('2026-12-25');

// 使用 .getTime() 轉成時間戳數字
console.log(christmas.getTime()); // 印出 2026 聖誕節的毫秒數

• 把時間戳轉成人類看得懂的日期：
  如果我們從後端 API 拿到了一串時間戳數字，只要把它丟進 new Date() 裡，就可以還原成正常的日期物件。

const apiTimestamp = 1790685000000;

// 將時間戳數字丟入 new Date()
const dateObject = new Date(apiTimestamp);

console.log(dateObject.toLocaleString()); // 轉成當地時間字串，如 "2026/9/29 下午9:30:00"

總結

時間戳就是電腦世界的大碼錶，記錄著從 1970 年第一秒開始到現在，總共走過了幾毫秒。