本文不涉及任何中高級的技術知識，僅為面向業務的科普。
前些天在 cnode 上看到網友的抱怨 一個日期的坑 ，內容如下：
而回復也多表示，這個“坑”是來自 Java 的。那么問題來了：
這個“坑”真的來自 Java 嗎？如果不是，又是來自何處？這個“坑”我們在業務中真要直接面對嗎？關于時間、日期等，還有沒有其它類似的“坑”？ Unix epoch 與 tm
大家都知道，Date.now() 或是 Date 對象的 () 方法可以得到一個數字，俗稱“時間戳”，或是“Unix 時間戳”。不少朋友還知道，常見的編程語言都能處理這個“時間戳”，也有不少在線工具可以幫我們將“時間戳”轉為可閱讀的時間日期，如 及 等等。這個“時間戳”，英文名為 Unix epoch、POSIX time，本質就是給定時間在 UTC 1970年1月1日零點之后的秒數。注意，在 TS、JS 等語言里使用的是毫秒數。
在 C 語言中，不晚于 C89 / C90 標準， 就已將 Unix epoch 對應的32位有符號整數定義為 。自然，C 語言也能將 Unix epoch 和具體日期的年月日時分秒等相互轉換。 tm 就是同樣定義于 的結構體， 和 / 就是 和 tm 的轉換函數。我們來看看 tm 的成員對象：
原來早在80年代的編程語言中，月份就以 [0, 11] 來表示了，Java 不是這個“坑”的源頭。
日期時間的格式化
顯然，這個“坑”多出在日期時間的格式化上。如果我們需要的是可閱讀的本地化時間、日期字符串，完全可以使用 Date 自帶的方法。
而對于類似 等自定義格式，.js 這個庫可以讓我們方便地在其與 Date 對象間雙向轉換。
日期時間的加減計算
之前提到，Date 對象的 () 方法可以取出毫秒單位的 Unix Epoch ，那么我們是不是可以基于此來取得給定時間之前或之后指定長的 Date 對象呢？當然可以。 同樣，.js 也為我們提供了方便的計算方法。
雖然二者可以達到一致的效果，我們在日常工作中還是應盡量使用后者，代碼中有意無意出現的 magic 是隨時可能爆炸的炸彈。你不能確定你的 86400 是不是多寫或者少些了一個零，或是忘了乘以 1000 。
相對時間與日歷時間
.js 還提供了帶本地化的相對時間與日歷時間輸出，這使得日期時間在不追求極端精確顯示的情況下具有更好的可閱讀性。
如僅想使用本地化的相對時間功能，.js 也是個不錯的選擇，本文不作詳述。注意在簡體中文環境下，.js 與 .js 對于將來時刻的輸出是有所不同的，.js 是“n 天內”，而 .js 是"n 天后"。
如果說日期時間的加減計算不使用任何第三方庫的問題不大，那么相對時間與日歷時間就完全不建議這么做了。舉個例子，時間單位的單復數就是大麻煩。更何況 .js 還自帶幾十種語言的本地化。
時長
看慣了便于閱讀的相對時間顯示，再看到慣用的 hh:mm:ss 的時長顯示，是不是瞬間覺得可閱讀行太差了呢？特別是當時長較長且策劃 / 產品經理死也不同意使用相對時間來顯示時，策劃 / 產品經理往往會給出一些毫無常識、宛如智障的顯示格式，比如... 01:02:03:04:05，這叫“一個月零兩天三小時四分五秒”。這種顯示，不是非蠢即壞，就是單純的又蠢又壞。遺憾的是，包括 .js 在內的大部分日期時間庫都沒有時長相關的處理。這里我們使用 來解決這個問題。
同樣支持多種語言的本地化。 參數決定著輸出結果的最大單位數量，越多則越精確但也更啰嗦，一般我們使用 1 或 2。
其它
大家大概都遇到過時區的問題，不過我們了解了 Unix Epoch 之后就應該明白，在存儲、傳輸時不要使用自己格式化產生的字符串或數字，而只使用 Unix epoch、 Date 對象、ISO格式的字符串（可由 Date 的 () 方法得到），在計算與顯示時使用 Date 內置的方法和 .js 等第三方庫，幾乎所有的坑都可繞過。
另一些較為罕見的問題就是夏令時和閏秒，上述原則仍然有效。值得注意的是閏秒的顯示秒數是 60java獲取當天零點的時間戳java獲取當天零點的時間戳，所以我們回頭查看 tm 的定義， 的范圍是 [0, 60] 。
總結
本文簡單帶過了 TS / JS 中的日期時間常見的問題及解決辦法。回到文章開頭的三個問題，精簡回答如下：
1. 這個“坑”真的來自 Java 嗎？如果不是，又是來自何處？
不，80年代的編程語言就是這么處理的。
2. 這個“坑”我們在業務中真要直接面對嗎？
不需要，盡量使用 Date 自帶的方法和第三方庫。
3. 關于時間、日期等，還有沒有其它類似的“坑”？
相對時間、日期時間與時長的本地化顯示，時區、夏令時、閏秒。
遵循存儲與傳輸是使用 Unix epoch、Date 對象等 raw data，計算與顯示時使用 Date 內置的方法和第三方庫的原則，能繞過幾乎所有的坑。