# 淺談時間

## 重點一：timestamp 的意義

timestamp 基本上有兩種，差在精確度

JS 的 timestamp 是最詳細的，一共有 13 位數，代表著：「從 UTC +0 1970-01-01 開始，過了多少`毫秒`」

1593755426950

另外一種則是少了 3 位數，只有 10 位數，代表著：「從 UTC +0 1970-01-01 開始，過了多少`秒`」

1593755426

所以你會發現有些地方需要把東西 / 1000 或者是 * 1000，就是在做毫秒的轉換。

## 重點二：timestamp 是中立的，跟時區無關

這句話的意思是，你今天拿到一個 timestamp 之後，你不會知道應該要顯示在什麼時區，因為同一個 timestamp 可以代表不同地區的時間。

舉例來說，1593163158 這個 timestamp 代表的是：

UTC +0 時區的 `2020-06-26 09:19:00`

同時也代表著：

UTC +8 時區的 `2020-06-26 17:19:00`

所以同一個 timestamp，在不同時區會被轉譯成不同的時間。

## 重點三：ISO 標準格式

在實務上不一定會直接傳 timestamp，有可能會用另外一些可讀性比較高的格式字串，常看到的可能會有：

1. `2020-02-02`
2. `2020-02-02 13:00:00`

看起來都十分合理，但其實用的時候都要小心，因為這些不一定是標準的 ISO 格式，如果不是的話，被解析時可能就會有些問題。

以第一種為例，可以猜猜看下面這兩行的結果是什麼：

 new Date('2020-02-02')
 new Date('2020/02/02')

.
.
.
.
.
.
.

答案是：

new Date('2020-02-02')
// Sun Feb 02 2020 08:00:00 GMT+0800 (台北標準時間)

new Date('2020/02/02')
// Sun Feb 02 2020 00:00:00 GMT+0800 (台北標準時間)

如果是用 `-` 隔開，會被當作是「UTC +0 時區的 2 月 2 號 00:00:00」

如果是用 `/` 隔開，會被當作是「本地時區的 2 月 2 號 00:00 :00」

因為我們在 +8 時區，所以這兩種的結果會差 8 個小時。

再來看看第二種格式：`2020-02-02 13:00:00`

這種格式的問題在於，在 Safari 上面會直接報錯給你看，回傳一個 `Invalid date`，不過這也滿合理的，因為它不是一個標準的格式。

你必須加一個 `T` 才能正確解析：

new Date('2020-02-02 13:00:00')
// invalid date

new Date('2020-02-02T13:00:00')
// Sun Feb 02 2020 21:00:00 GMT+0800 (CST)

那這樣就沒了嗎？不是。以上面那個字串為例，它在 Safari 上面與 Chrome 上面解析的結果不一樣：

// Chrome
new Date('2020-02-02T13:00:00')
// Sun Feb 02 2020 13:00:00 GMT+0800 (台北標準時間)

// Safari
new Date('2020-02-02T13:00:00')
// Sun Feb 02 2020 21:00:00 GMT+0800 (CST)

就跟前面講的 `-` 與 `/` 類似，如果沒有在 date string 裡面指定時區，會有兩種情況：

1. Chrome 自動解析為：「本地時區」的 13:00
2. Safari 自動解析為：「UTC +0 時區」的 13:00，所以換到 +8 就變成 21:00 了

而這上面這麼多坑，其實都是因為沒有正確利用 ISO 標準格式所導致，如果用了 ISO 的格式：`YYYY-MM-DDTHH:mm:ssZ` 就沒這問題了。

只要在最後面加個 Z，就代表 UTC+0 的時區，所以解析就會正常。當然，你也可以傳不同時區進去。

new Date('2020-02-02T13:00:00Z')
// Sun Feb 02 2020 21:00:00 GMT+0800 (台北標準時間)

new Date('2020-02-02T13:00:00+08:00')
// Sun Feb 02 2020 13:00:00 GMT+0800 (台北標準時間)

## 重點四：date string 的時區小陷阱

請問以下程式碼的結果會是什麼？

luxon.DateTime
  .fromISO('2020-02-02T13:00:00+03:00')
  .toFormat('HH:mm:ss')

.
.
.
.
.
.
.

答案：

18:00:00

date string 帶時區，就會讓你誤以為 format 出來的結果會跟著這時區，但實際上卻不是這樣。toFormat 的結果會是本地時區。

可以簡單想成任何的 date string 在做處理時，內部都會先轉成 timestamp，然後再用「本地時區」來處理。

所以：

`fromISO('2020-02-02T13:00:00+03:00').toFormat('HH:mm:ss')` 其實就跟 `fromMills(1580637600000).toFormat('HH:mm:ss')` 是一樣的

## 那到底應該怎麼做？

如果你今天拿到一個 date string，你在 format 的時候想用原來的時間來做 format，可以這樣：

luxon.DateTime
  .fromISO('2020-02-02T13:00:00+03:00', { 
    setZone: true
  })
  .toFormat('HH:mm:ss')

// 13:00:00

如果你今天拿到一個 date string，你想要用「固定時區」來轉換，可以這樣：

luxon.DateTime
  .fromISO('2020-02-02T13:00:00+03:00', { 
    zone: 'Asia/Tokyo'
  })
  .toFormat('HH:mm:ss')

或者是：

luxon.DateTime
  .fromISO('2020-02-02T13:00:00+03:00')
  .setZone('Asia/Tokyo')
  .toFormat('HH:mm:ss')

總結一下在多個時區的時候的處理：

1. Backend 永遠回傳 ISO 標準格式：`YYYY-MM-DDTHH:mm:ssZ`
2. 前端在「顯示」時，轉成需要的時區