網頁設計
我是 Sasha @kossnocorp。
我很高興地宣布 v4.0 版本發布,其中包括一流的時區支持,並且沒有重大更改。
對於 TL;DR,請參閱時區檔案和變更日誌。
時區支持
這是最令人期待的功能之一。 date-fns-tz
作者:Marnus Weststrate,我多年來一直推薦它。
說實話,我沒有太多處理時區的經驗,也沒有良好的 API 的願景,而且我看到的所有建議都感覺不太好。 date-fns-tz
到 date-fns
下載率(3.2M/21.7M~15%)顯示我是對的。是的,在Intl API 廣泛普及之前,它需要一個重量級的IANA 資料庫。 date-fns-tz
淨化馬努斯的工作無效。
2022年,我想長大 @date-fns/utc
立即感覺正確。但我又花了兩年時間才弄清楚如何實現它。
現在我終於很高興地說它就在這裡。 @date-fns/tz
提供 TZDate
(以及一些輔助函數)適用於所有 date-fns 函數:
import { TZDate } from "@date-fns/tz";import { addHours } from "date-fns";// Given that the system time zone is America/Los_Angeles// where DST happens on Sunday, 13 March 2022, 02:00:00// Using the system time zone will produce 03:00 instead of 02:00 because of DST:const date= new Date(2022, 2, 13);addHours(date, 2).toString();//=> 'Sun Mar 13 2022 03:00:00 GMT-0700 (Pacific Daylight Time)'// Using Asia/Singapore will provide the expected 02:00:const tzDate= new TZDate(2022, 2, 13, "Asia/Singapore");addHours(tzDate, 2).toString();//=> 'Sun Mar 13 2022 02:00:00 GMT+0800 (Singapore Standard Time)'
之前,在 v3 中,你無法混合 UTCDate
和 Date
進行討論,而不用冒險得到很快的結果。Date
或一個 Date
擴展實例)。
它允許您混合併匹配不同類型的時區,而不會冒計算錯誤的風險。
但是,結果仍然可能會有所不同,具體取決於參數的順序:
import { TZDate } from "@date-fns/tz";import { differenceInBusinessDays } from "date-fns";const laterDate= new TZDate(2025, 0, 1, "Asia/Singapore");const earlierDate= new TZDate(2024, 0, 1, "America/New_York");// Will calculate in Asia/SingaporedifferenceInBusinessDays(laterDate, earlierDate);//=> 262// Will calculate in America/New_YorkdifferenceInBusinessDays(earlierDate, laterDate);//=> -261
因此,為了解決這個問題,大多數 date-fns 函數(所有時區可能影響結果的地方)都接受上下文選項 in
允許明確指定要使用的時區:
import { tz } from "@date-fns/tz";// Will calculate in Asia/SingaporedifferenceInBusinessDays(laterDate, earlierDate);//=> 262// Will normalize to America/Los_AngelesdifferenceInBusinessDays(laterDate, earlierDate, { in: tz("America/Los_Angeles"),});//=> 261
無論是從實作還是API的角度來看,我對結果都非常滿意。
另外,您也可以同時使用 @date-fns/tz
和 @date-fns/utc
沒有 date-fns ,仍然可以獲得價值。
這是我一直在尋找的 date-fns 方法。
我前面提到的,時區不會為核心庫增加太多開銷,而且大部分功能都是由外部和可選的處理的 @date-fns/tz
Bundlephobia 表示,包裹總尺寸從 17.2 kB
到 17.5 kB
。 300 B
增加,我認為這是非常好的。
因為 TZDate
本身,它的最小版本, TZDateMini
,只是 761 B
,新增字符串格式的完整版本是 1 kB
。
UTCDate
甚至更小,與 UTCDateMini
只是 239 B
和完整版 504 B
,比競爭對手小近五倍。
重大變化
在 v3.0 公告中,我建議我要擺脫 CommonJS 支援。一年的時間,而上一次迭代花了4年時間,加上ESM覆蓋對生態系統的整體不良影響,我決定再等一會兒。 "type": "module"
在 package.json
,而不是 .mjs
,它有 .cjs
這不應該影響任何人,除了那些對內部做了一些有趣的事情的人。
我還必須更改一些類型,主要是函數泛型。如果確實如此,我相信修復將是微不足道的。
這個版本打破了資源共享的主要版本,並進行了許多重大的改變,我打算保留這種方式。
v5.0 及更高版本
我違反的另一個傳統是兩次發布之間有很多年的間隔。 ,就像v4.0一樣。
現在,在我最終解決時區問題之後,我將為缺少的功能(例如持續時間、全局區域設定或任何其他仍然存在的date-fns 盲點)提供更多空間,並且我將使date-fns 成為功能完整的日期時間圖書館。
我最大、更抽象的目標之一是完成向國際 API 時代的過渡,並為即將到來的 Temporal API 做好準備。
和 format
同時仍然是最常用和最重要的功能,這將有利於推動開發人員採用更輕量級和更強大的國際API。例如 @date-fns/es
完全基於 Intl 的格式成為當前的預設方式。
我還在工作中進行了臨時 API 實驗,這是一個輕量級的 Temporal API 子集,可以幫助開發人員現在以及需要遷移時開始使用它——只需替換並替換類別名稱或導入即可。
當然,Temporal API 的最終目標是擁有一個可以配合使用的 date-fns 版本,同時仍然保持 Date
該庫的版本將持續數年甚至跋年。
你可以看到我對 v5.0 沒有具體的計劃。 ,或向我發送一條不錯的DM。
乾杯,薩沙@kossnocorp