AI製アプリの時刻表示がズレる理由タイムゾーンの直し方

なぜAI製アプリの時刻表示はズレるのか?

離れた場所にいる2人が、それぞれ正しい時刻を見ているのに、画面には違う数字が表示される——タイムゾーン問題とは要するにこれだ。マドリードの顧客が午後3時の枠を予約する。あなたはメキシコシティにいて、画面には同じ予約が午前8時と表示される。思わず二度見して、何かが壊れていると確信する。

何も壊れていない。マドリードの午後3時と、メキシコシティの午前8時は、まったく同じ瞬間だ。どちらも正しい。この「2人とも正しいのに数字が違う」というズレこそが、「アプリの動きがおかしい」というバグ報告の意外に多くの原因になっている。

このズレに気づきにくいのは、開発中やテスト中は自分ひとり、ひとつの場所、ひとつの端末で作業しているからだ。すべてがぴったり噛み合って見える。タイムゾーンが牙をむくのは、別の場所にいる_もう一人_が同じ時刻を見たときだけだ。あなたのアプリに複数都市のユーザーがいる、あるいは何らかの予約送信メッセージを扱っているなら、いずれ必ず直面する問題だ。備えておくに越したことはない。

タイムゾーンとは、そもそも何か?

タイムゾーンとは、時刻の「場所」の部分——ある普遍的な瞬間を、その土地の時計の読みに変換する仕組みだ。ここを押さえれば、あとの話は一気に腑に落ちる。すべての時刻には2つの要素がある。

瞬間 — 地球上どこでも同じ、たったひとつの時点。
場所 — 時計を読んでいるあなたがいる場所。

「午後3時」それ単体では意味を持たない。_どこの_午後3時か? コンピュータはこれを、場所に依存しない中立な形式(あなたのビルダーが「UTC」と言うのを耳にするはずだ——固定された基準点の時計だと思えばいい)で瞬間を保存し、実際に誰かが見るときに、その人のローカル時刻へ変換して表示することで対処している。

アプリの時刻表示がズレるのは、ほぼ必ずこの2要素のどちらかを見失っているからだ——場所を忘れているか、そもそも本当の「瞬間」を保存していないかのどちらかだ。

アプリでタイムゾーンのバグが起きる原因は?

ほぼすべてのタイムゾーンバグは、次の3つの具体的なミスに起因する。時計の表示だけを保存して本当の瞬間を保存していないこと、サーバーのタイムゾーンを表示してユーザーのタイムゾーンを表示していないこと、そして夏時間の切り替えを無視していることだ。

1. アプリが「瞬間」ではなく「表示」を保存している。 誰かが「午前9時」を選ぶと、アプリは場所の情報なしに「午前9時」というテキストだけを保存する。すると、どこの誰に対しても「午前9時」と表示される。これは望ましい場合もあれば(各人の_現地時間_の午前9時に鳴ってほしい服薬リマインダーなど)、大惨事になる場合もある(全員にとって同じひとつの瞬間に始まるべきライブウェビナーなど)。アプリがどちらの意図なのか判断を誤ると、時刻はズレていく。

2. アプリがユーザーの時刻ではなく、サーバーの時刻を表示している。 あなたのアプリはデータセンター内のコンピュータ上で動いている——たとえばバージニア州だとしよう。特に指定しなければ、アプリは平然と全員にバージニアの時刻を表示する。ロンドンのユーザーは実際とは半日分ずれた時刻を見せられ、なぜそうなるのか理解できない。

3. 夏時間が時計をずらしても、アプリが気づかない。 多くの地域では年に2回、時計を1時間ずらす。冬に設定した「毎週火曜午前9時」の定例ミーティングは、アプリが「場所」ではなく「固定のオフセット」を基準にしていると、夏には突然午前8時や10時になってしまう。

実際にあった3つのケース

3回始まったイベント。 ある創業者が、オンラインワークショップ用のシンプルなページを作り、開始時刻をひとつだけ「午後6時開始」と記載した。3か国の参加者はそれぞれ「午後6時」を自分のローカル時間の午後6時として読んだ。3分の1は1時間遅れて参加し、数人は1時間早く参加し、全員がリンクのせいだと思い込んだ。必要だったのはより良いリンクではなく、各人に_その人自身の_現地開始時刻を、タイムゾーンを明記した上で表示することだった。

午前2時に届いたニュースレター。 「毎朝午前8時に送信」というメールは、サーバー側の午前8時に送信されていた。購読者リストのヨーロッパ側の人々にとって、それは真夜中だった。その層の開封率は惨憺たるもので、一見コンテンツの問題に見えた。実際はタイムゾーンの問題だった。

日曜日の予約重複。 ある予約アプリで、時計が「1時間戻る」夜に、2人が同じマッサージの枠を予約できてしまった。その夜は午前1時30分が2回訪れ、アプリはそれらを同じ瞬間として扱ってしまったからだ。めったに起きないが、本物の顧客と本物の謝罪を失うタイプのバグだ。

タイムゾーンを直すために、ビルダーに何を頼めばいいか?

平易な言葉で、次の4点を具体的に依頼しよう——細かい仕組みを理解する必要はない。以下をそのままコピーして使ってほしい。

「すべての時刻をUTCの瞬間として保存し、あわせて各ユーザーのタイムゾーンも保存してください」

「時刻を表示するときは_見ている人の_タイムゾーンで表示し、午後3時(あなたの現地時間)や午後3時 CSTのように、タイムゾーンをその場に明記してください」

「リマインダー、スケジュール、繰り返しイベントなど繰り返し発生するものはすべて、固定の時間数ではなく『America/Mexico_City』のような場所に紐づけてください。そうすれば夏時間は自動的に処理されます」

「自分が別の国にいるつもりでテストさせてください」

最後の項目は見た目以上に重要で、これは次の「自分でできること」の話につながる。

アプリのタイムゾーンのバグはどうテストすればいいか?

別の国にいるユーザーがいなくても、ほとんどのタイムゾーンバグは2分でチェックできる——別の国にいるふりをすればいいだけだ。

スマートフォンやパソコンの日時設定を開き、タイムゾーンを遠く離れた場所——東京でもロンドンでもどこでもいい——に切り替える。
アプリを再読み込みする。
時刻が表示されるすべての箇所を確認する。ちゃんと意味の通る時刻になっているか? _誰の_時刻なのかが分かるようになっているか?

本来午後3時のはずの予約が何の説明もなく午前4時と表示されていたら、顧客より先にバグを見つけたことになる。確認が終わったら設定を元に戻すのを忘れずに。繰り返しリマインダーや夏時間のケースについては、別の国にいる友人ひとりに、ある特定の日付を見てもらい、何時に見えるか教えてもらうのが一番確実な確認方法だ。

そもそもタイムゾーンを気にする必要はあるのか?

正直なところ——時には気にしなくていい場合もあり、それは言っておく価値がある。アプリを使う人が全員同じ都市にいるなら——地元のレストランのシフト管理ツールや、近所のクラブの申込フォームなど——難しい部分の大半は省いてかまわない。表示を一貫させ、時刻にラベルを付けて誤解の余地をなくすだけでいい。

タイムゾーンが本当の懸念事項になるのは、次の2つのどちらかが当てはまる瞬間だ。離れた場所にいる2人が同じ時刻を共有する、またはアプリが何かをスケジュールに沿って送信する。この一線を越えた瞬間から、最も安上がりで最もシンプルな保険は、時刻の隣に必ずタイムゾーンを表示することだ。この習慣ひとつだけで、こうした問題の大半を引き起こす曖昧さは取り除ける。より根本的な修正を入れる前からだ。

だから次にアプリに日付や時刻のフィールドを追加するときは、先に進む前にひとつだけ自分に問いかけてほしい。これは誰の時刻か? この問いに声に出して答えられるなら、あなたはすでに世の多くのアプリより一歩先を行っている。