日付まわりの表示は、サイトを作っていればどこかで必ず触ることになります。予約フォームのカレンダー、記事の投稿日、営業日の一覧。一見どれも単純ですが、対象の地域が変わると前提そのものが変わります。週の始まりは日曜なのか月曜なのか、週末はどの曜日にあたるのか、どの暦を併記するのか。こうした知識は、これまでブラウザの外から持ってくるしかありませんでした。

2026年7月、JavaScriptの国際化機能であるIntl.Localeに加わった一連のメソッドが、主要ブラウザすべてで使える状態になりました。web.devの月次まとめによると、Firefox 153が対応したことで、Baselineの「新しく利用可能」に入ったとされています。地味な機能ですが、カレンダー部品を自作したことがある人ほど、ありがたみが分かる種類の追加です。

これまでは辞書を自前で抱えていた

「この地域では週が月曜から始まる」といった知識は、CLDRという国際的なデータベースにまとめられています。ただ、ブラウザからその中身を直接引く手段が長らくなく、カレンダーの見た目を自分で組む場合は、データの一部を写し取ったライブラリを読み込むのが普通でした。週の初日を表す値ひとつのために、数十キロバイトの追加読み込みが発生することも珍しくありません。

Intl自体はかなり前からあり、Intl.DateTimeFormatを使えば日付を地域の書式に整えることはできました。ただしそれは整形済みの文字列が返ってくるだけで、UIを自分で組み立てるために必要な素の情報、たとえば曜日を並べる順番の起点までは取り出せません。今回埋まったのは、ちょうどこの隙間にあたる部分です。

Intl.Localeから引けるようになった情報

書き方は素直で、ロケールを表すオブジェクトを作ってメソッドを呼ぶだけです。new Intl.Locale("ja-JP").getWeekInfo() のように書くと、週の始まりの曜日、週末にあたる曜日、その年の最初の週とみなすための最小日数がまとめて返ってきます。曜日は1が月曜、7が日曜という決まりになっています。

同じ要領で、その地域で使われる暦の一覧を返す getCalendars()、時刻を12時間制と24時間制のどちらで扱うかを返す getHourCycles()、文字を左から右に並べるか右から左に並べるかを返す getTextInfo()、地域に結び付いたタイムゾーンの一覧を返す getTimeZones() が用意されています。ほかに数字の表記体系や並べ替えの規則を返すものもあり、いずれも MDNのIntl.Localeのページに一覧があります。

返ってくるのは配列や小さなオブジェクトなので、そのまま画面に出すというより、自分のUIの初期値として使う性格のものです。

日本語のサイトで効いてくる場面

日本のロケールで getCalendars() を呼ぶと、グレゴリオ暦と和暦の識別子が返ってきます。行政関連の書類を扱うサイトや、年号の併記が求められる申込フォームでは、この結果を起点にIntl.DateTimeFormatへ和暦を指定する、という流れが自然に組めます。和暦を出すかどうかを地域の慣習として扱えるので、判定を自前のif文で書き分けずに済みます。

週の始まりも実務的です。日本語圏では日曜始まり、英国では月曜始まりというように、カレンダーの見た目は地域で割れます。多言語対応のサイトで同じカレンダー部品を使い回すとき、対応表を自分で抱えなくてよくなるのは負担が減るところです。予約カレンダーや営業日の表示は、中小企業のサイトでも決して珍しい要素ではありません。

使う前に確認しておきたいところ

Baselineの「新しく利用可能」は、主要ブラウザの最新版で動くという意味であって、少し前の端末まで含めて安全という意味ではありません。企業サイトの訪問者には更新の止まった端末も混ざりますから、メソッドがあるかどうかを確かめて、無ければ従来どおりの既定値を使う、という組み方が現実的です。値が取れなくても表示が壊れないようにしておけば十分です。

もう一点、以前の実装ではメソッドではなくプロパティとして提供されていた時期があります。古い解説記事のコードをそのまま持ってくると動かないことがあるので、参照する情報の新しさには注意しておきたいところです。

外部ライブラリに頼っていた小さな機能が標準側に移ると、依存パッケージがひとつ減り、更新の手間もその分軽くなります。派手さはありませんが、次にカレンダーまわりを触る機会があれば、置き換えられる部分がないか見ておく価値はありそうです。