下記のエントリが少し話題になっていた。
タイムゾーンにはUIをどうするかという問題がつきまとうことがあるということを常々思っており、それは知識編にあるべきだと思っていたが実装編の「確定した過去の時刻か? 未来に予定された時刻か?」という部分にいろいろ書かれていた。
具体例として僕がこれまで見てきた面倒くさそうなトピックをここに残しておく。
メールなどの受信時刻の表示
MUAなどでメールの一覧が出るとき、受信時刻が表示されることが多い。一覧に表示されなくても詳細画面には表示されているだろう。通常のMUAでは内部では受信時刻はたぶんUTCで保存されていて、それを表示するときにローカルなタイムゾーンに戻して表示している。
だから、端末のタイムゾーンを変更すると、これまでに受信したメールの受信時刻表示が一斉に切り替わるというような挙動になっているものがほとんどである。
しかし僕がiモード端末の開発を行っていたときのFOMA 端末のメール機能の担当は、このような動きは一般の消費者には理解できないと判断したのか、「メールの受信時刻は、受信したときのローカルタイムで表示すること」仕様に決めた。
たとえば成田→シアトルの直行便、7月5日の18:00に成田を飛び立つとシアトルに着くのは現地時間では7月5日の11:00になる。当時のケータイではひっきりなしにメールが来ることは普通にあったので、表示される時刻の順でソートしてはいけないことになる。
受信したときのタイムオフセットとUTCを保存して、表示時にそのタイムオフセットを計算して表示するか、受信したときのローカルタイムとUTCを保存しておく方式とどちらがいいかの話になったとき、ユーザーの要求が「受信したときの時刻を維持してくれ」だったので後者のほうが素直に要求仕様に従っている、ということで後者を推奨した記憶がある。僕はそのころメインはiアプリ担当だったので最終的にどちらの実装になったのかは知らない。
現在と違うタイムゾーンの予定時刻を表示しないといけない場合
これは難しい。たとえばカーナビで設定した経路がタイムゾーンの境界をまたがるとき、到着予定時刻をどちらの時刻で表示すべきか。飛行機では現地のローカルタイムでの現在時刻と、その現地での到着予定時刻を並べて表示することで理解を促している。
定期的な予定
フランスのパリのスケジューラで夏に毎週月曜日AM8:00開始のスケジュールを入れた。これは日本では15:00開始である。サマータイムをまたがったときにどうなるべきか。当然サマータイムをまたがる現地では冬になってもAM8:00のままであり、だからこの予定を日本のタイムゾーンで見ると、10月までは毎週15:00だが10月最終週からいきなり毎週16:00にスケジュールが入っていることになる。
一方で日本で同じ時刻(毎週15:00開始)に繰り返しスケジュールを入れた場合、日本では10月以降も15:00開始は変わらず、パリ側ではAM8:00開始の予定が、10月最終週以降はAM7:00開始になる。
iPhoneのカレンダーアプリではこれが正しく実装されており、繰り返し予定の詳細を確認するといまのローカルタイムでの予定時刻と、その予定が入力されたタイムゾーンでの時刻の両方が表示される。丁寧に正しく作られている。
夏時間をまたがるタイムテーブル
BBCのタイムテーブルを見るとこのようになっていた。このようなケースがあるということがUI仕様として周知されていない場合、「なぜ実装がそのように複雑になるのか」「サマータイムなど、OSが対応していればちゃんとしたプログラムであれば何もしなくても対応できるはずだ」と怒られたり、要らぬバグチケットが切られたりする現象が発生する。
BBC News Channel - Schedules, 19 - 25 October 2020
「OK Google。明日のハンガリーの天気は?」
僕は7/4の日本時間の午前中早い時刻にこれを言った。Google Homeの回答は「今夜のハンガリーは、…」だった。その「今夜」が7/3の夜のことなのか、7/4の夜のことなのかはよくわからなかった。
