タイムゾーンの一覧を、間違えずに読む
タイムゾーンの一覧は、実際にひとつ選ぶまではただの資料に見えます。選ぶ段になって初めて疑問が出てきます。同じオフセットの項目が三つあるのはなぜか、識別子は何のためにあるのか、API が求めているのはどれなのか。
識別子はオフセットとは別物
ここにある項目はすべて IANA のタイムゾーン識別子で、「地域／都市」の形をしています。Europe/Berlin、America/Argentina/Buenos_Aires、Asia/Kolkata。識別子が指しているのは地域とルールの集合です。隣に並ぶ UTC+02:00 のような数字は、そのルールが今日たまたま導く結果にすぎません。
この違いは、ゾーンが変わった瞬間に効いてきます。Europe/Berlin は何年も冬が UTC+01:00、夏が UTC+02:00 で、識別子は一度も変わっていません。識別子と一緒に保存した時刻は永遠に曖昧さがなく、裸のオフセットだけを保存した時刻はそうではありません。
略号は当てにならない
CST は北米の中部標準時でも、北京の中国標準時でも、ハバナのキューバ標準時でもあります。IST はインド、アイルランド、イスラエル。BST は英国夏時間であり、バングラデシュ標準時でもあります。
略号は一意でも標準化されてもおらず、識別子の一部でもありません。略号で並べ替えた表は、十一時間離れた都市を隣り合わせに置きます。スケジュールの事故はたいていそうやって起きます。
Etc/GMT の符号の罠
Etc/GMT+5 や Etc/GMT-5 といった固定オフセットのゾーンは、直感と符号が逆です。Etc/GMT+5 は UTC より五時間遅い、つまり UTC−05:00 を意味します。この約束は POSIX の TZ 変数に由来し、わかりやすさのためではなく互換性のために残されています。
一定のオフセットが必要なだけなら、オフセットをそのまま書いて識別子は使わないこと。IANA の文字列をどうしても要求される場合にだけ Etc/GMT を選びます。
オフセットが同じでもルールは違う
二つの都市が一年中同じオフセットでも、別々の識別子が必要なことがあります。背景にあるルールが違うからです。Asia/Shanghai と Asia/Singapore はどちらも UTC+08:00 で夏時間はありませんが、履歴の異なる別項目として登録されています。
もっともらしい近道が壊れるのはここです。誤った識別子で組んだカレンダーは、今日の時刻は正しく、五年前の日付は間違います。そして多くの場合、誰かが過去の記録を照合するまで気づかれません。
検索と絞り込み
検索ボックスは識別子に対して照合します。都市名が識別子に含まれていれば一致するので、「Shanghai」で Asia/Shanghai、「Buenos」で America/Argentina/Buenos_Aires が見つかります。国名とオフセットでは検索できません。
地域ボタンは一覧を単一の上位地域に絞ります。America、Europe、Asia、Africa、Australia、Pacific、Atlantic、Indian、Arctic、Antarctica。最近の選択はブラウザに保存され、サーバーには送信されません。