Temporalにおけるタイムゾーンの曖昧性
https://tc39.es/proposal-temporal/docs/ja/ambiguity.html
Temporalで解決しようとしている問題の一つ
サマータイムやタイムゾーン変更が絡むとExact Time → Wall-Clock Timeは一意に決まるけどWall-Clock Time → Exact Timeは一意に決められない問題
サマータイムやタイムゾーン変更による問題
Exact Time → Wall-Clock Time
これは一意に決まる
Wall-Clock Time → Exact Time
これが一意に決まらない
サマータイム : サマータイムは開始時と終了時に同じ時刻が2回出現したり、特定の一時間が無くなったりする
タイムゾーン変更 : 今後変更される可能性があり、本来想定されていたオフセットと新しいオフセットが衝突する可能性
丁度この時間を持ったWall-Clock TimeをExact Timeに変換しようとすると、どちらを指しているかは曖昧になる。
一位に定まらないのはいた仕方ないので
サマータイムの曖昧性に対するTemporalでの解決策
Exact Timeに変更するようなメソッドには「曖昧な時どう解決するか」のオプションであるdisambiguationオプションがある
'compatible'（デフォルト）: タイムゾーンが負の方向へ変化している範囲では'earlier'、正の方向へ変化している範囲では'later'として振る舞う。
'earlier': 2 つの exact time のうち、早い方が返却される。
'later': 2 つの exact time のうち、遅い方が返却される。
'reject': RangeErrorが投げられる
'compatible'は moment.js や Luxon、date-fns の動作と一致
RFC 5545 (iCalendar)の挙動とも一致
タイムゾーン定義変更による曖昧性の解決策
基本的に過去のタイムゾーン定義を変えることはないので、基本的には未来の話
ただ未来の日時を扱うことはよくある
Temporal.ZonedDateTimeのfrom()メソッドにoffsetオプションがある
'use' : 与えられたタイムゾーンオフセットを優先する。
'ignore': 最新のタイムゾーン定義から得られるオフセットを用いる
'prefer':与えられたオフセットがそのタイムゾーンで有効ならそちらを採用。もし無効なら、新のタイムゾーン定義から得られるオフセット
'reject': 入力されたタイムゾーンにおいて、与えられたオフセットが無効な場合はRangeError