如果你喜歡這內容的話幫我在 Twitter 和 Threads 上面分享給其他正在前端這條路上努力的朋友們，也別忘了訂閱我們電子報收到第一手消息喔 🚀
最近在跟我們的 Staff Engineer 就是上次邀請上來的 Braden 遊說其他人說官網之後應該要用 App Router 開始做開發了，目前我們做的 POC 是預估可以砍掉使用者 80% 使用者需要下載的 JavaScript 而且也可以很好的預防上次發生過的 data leaking 畢竟那些 data fetching 都是在 server 上面做而我們也不需要把那些資料傳回使用者或是再 fetch 一次做 rehydration。目前得到的 feedback 是大家都滿興奮的所以可以期待一下，不過應該不會很快因為下一個重大的 project 是五月要做完但至少可以期待一下。
前兩個禮拜因為朋友邀請幫忙做了兩場模擬面試，一場中文前端一場英文系統設計，因為畢竟我算是北美這一套所以算是一個機會 showcase 北美面試中會注重在什麼地方或是流程大概是怎麼樣，有些題目比如 React diffing algorithm 是什麼或是 Vue component lifecycle 什麼的這種題目在北美應該很少聽說，工程師招進來是要會是用工具和技術來解決問題，除非公司的產品跟這些東西有關要不然每間公司都問這類問題說實話沒辦法保證這個工程師是最適合公司的，那系統設計環節就是透過不斷的問問題和面試官釐清需求也了解面試官其實想要問哪一方面的，通常面試時間緊迫有些面試官可能會有一些他們自己比較在意的點所以如果能回答那些反而更容易加分，那因為是面試不一定是真的有這樣的問題所以需要做假設但不能預設立場，如果預設立場而沒有解釋為什麼是會扣分的等於你沒有釐清需求或是了解問題最後就是缺乏溝通。
最近不曉得為什麼想試試看不同的 code editor，從一開始的 Sublime、Bracket、Atom、到現在的 VSCode 也用了好久好久了，想看看其他方案有什麼，Zed
今天想聊聊時間，這不是老高節目不是想討論時間從哪裡來的，而是說網站通常都怎麼處理時間和時區，假如你們的網站沒有這類需求或是只有給比如台灣人使用那可能沒什麼問題，但如果是那種一個國家有跨時區的甚至全球的那就有差別了。假設你說你的新產品是早上十點開賣，請問是哪裡的十點？假如是美國西岸的十點那如果我在台灣這時間應該顯示幾點？有些地方的時區還有那種差半小時的或是像北美以及其他地區有夏令時間在夏天時候時差會減一小時，這些應該怎麼處理。
首先這些時間應該怎麼儲存在 database 裡面，通常為了方便轉換也確保不會出錯都會把時間轉成 UTC 再存到 database 裡面，UTC 就是時區是零的地方所有的時區比如溫哥華現在的 -7 和台灣的 +8 都是用 UTC 當 reference point，時差什麼的再怎麼變都是以這個 UTC 為基準所以這是不會變的，那存這個通常有兩種方法，一種是 date string 就是人看得懂一看就知道是西元哪一年哪一個月幾小時等等，有很多 format 但通常會用比較 universal 的 ISO 8601 各式，另一種方法是 epoch 就是從 1970-01-01 到現在過了幾秒，兩種方式都可以但 epoch 是純數字比較好存也省空間，對有些 database 來說也好 index。
在前端要處理時間我們有 Date object，該有的都有比如轉 ISO 顯示 UTC 時間等等，但因為瀏覽器多不免會出現 API 不一致的問題，像不記得是哪一個 API 但 Chrome 會給你 UTC 時間但 Firefox 會給你 local 時間，這樣就很不 reliable，然後慢慢的就會有一些跟時間有關的 library 個工具讓我們前端使用，這在比如我們需要根據設計師或產品要求有特定的日期顯示方式時候特別好用，比如這邊只要年月日而這一頁只需要時間，也有分要不要顯示 AM PM 或是其他比較細節的東西，最一開始我們有 moment 這個 library，更進一步的如果需要顯示時區或是顯示其他地區的時間我們有 moment-timezone，這在一開始 Web API 沒有很完善的時候非常好用但隨著時間推移慢慢的有更好用的工具或是輕便的 library，像 moment-timezone 其實是有很大的 JSON 把每個地方的時區全部記下來也包括他們的夏令時間。萬一哪天過了很久你沒有維護升級可能時間就會出錯。
除了 moment 這個 library 以外我們也有其他的選擇，你每個都可以看一下其實都大同小異就是看你習慣哪一種 API 或是有沒有你想要的功能，比如寫 moment 的那個人寫了一個新的叫做 Luxon 主打 timezone，date-fns 和 dayjs 也都是不錯的選擇而且 code 都很現代化，不過如果你要的功能沒有特別複雜，現在的 JavaScript 有個 API 叫 Intl，裡面包含了很多跟 localization 有關的東西也包含了時間的 formatting，這樣或許還可以少一個 library 需要安裝，順帶一題如果你們需要應付 i18n 那除了語言、幣值、時間肯定也要考慮。
我記得在前公司時候第一次正式要做 Black Friday 活動所以需要某一個特定時間開始，北美橫跨三個時區所以 marketing 說能不能在每個時區的半夜 12 點開始活動，考慮到我們有 cache 而且對使用者來說這樣不同步就很奇怪，東岸會比我們西岸早三個小時買東西會不會都被他們買走了，最後就是以我們西岸時間半夜 12 點為基準這樣東岸凌晨三點才開始，時間這東西我們想的理所當然所以常常忽略但若真的忽略會很麻煩的。
可能 tc39 看到了 Date 一些缺點比如日期間的計算或是時區的支援，以後有個 Temporal API 幫助我們做這些本來需要第三方 library 才能做的事情，本來想介紹 Temporal 但看了 API 感覺除了 formatting 以外其他都可以做了，如果需要處理農曆時間據說也可以做到，目前在 Stage 3 意思是快要穩定了，等穩定就會正式納入 JavaScript spec 裡面然後每個瀏覽器應該都要有支援。