😺

終日予定がタイムゾーンでズレるのは当たり前というはなし

に公開

終日予定がズレるのは仕様です!

カレンダーやスケジュールアプリを作ってると、誰しも一度はハマる沼があります。
それが 終日予定がタイムゾーンでズレる問題

「え、なんで7月9日の予定が、アメリカで見ると7月8日になってんの!?」
「わたしの誕生日が1日早まって通知きたんだけど(怒)」

。。。ってユーザーから言われて、ヒヤッとしたことがあるあなた。
わかります、その気持ち。僕も最初そうでした。

仕事でタイムゾーン対応を行っていて、この問題にちょいちょい直面します。

でも大丈夫。これはバグじゃないです。

時差がある地球に生きる我々の宿命なんです。

グローバル対応するためには避けては通れない問題です。


終日予定、見た目はシンプル。でも中身は…

カレンダーで「終日」って言うと、普通は
「その日ずっと、朝から晩まで」って意味ですよね。

たとえば、
7月9日(水): 山田さん誕生日🎂
って感じ。

でも、DBの中ではどう保存されてるかというと…

start: 2025-07-09T00:00:00  
end:   2025-07-10T00:00:00  
timezone: UTC

……うん、なんか思ったより“ピンポイント”で保存されてるんですよ。
「終日」っていう割に、0時ジャスト〜翌日の0時ジャスト。
つまり 「24時間ぴったり」なイベント として保存されてる。
(さらに言えば一日が24時間だと思っているとサマータイムで痛い目を見ます)

この仕様、よくあるやつなんですが、ここで問題が起きます。

(いや、JSTで保存しろよってツッコミもあるとは思いますが、それはそれで問題が起きます。今回は話をわかりやすくするため割愛)


タイムゾーンが変わると「日付」が変わる!

たとえばこの予定、日本時間(UTC+9)で見てみると…

start: 2025-07-09 09:00  
end:   2025-07-10 09:00  

えっ、ちょっと待って。
なんで朝9時〜翌朝9時になってるの!?

そう、これが時差の威力です。
UTCで保存されてるから、日本で見たら9時間ズレるんですよ。

しかもこれをアメリカ西海岸(UTC-7)で見たら?

start: 2025-07-08 17:00  
end:   2025-07-09 17:00  

おいおいおい、7月9日の予定だったのに、8日に突入しちゃってるよ!
これ、マジで初見殺しです。


「それ、バグじゃないんです」って100回くらい説明したくなる

ユーザーから見たら完全にバグっぽい動作。
でも開発者としては「そう設計されてるから…」としか言えない。

これ、バグじゃないんです。
仕様です

終日予定って、実は「日付」じゃなくて「時間帯」なんですよ。
タイムゾーンによってその“終日”がいつなのか 開始時刻と終了時刻がズレて変わってしまう。

「え、地球ってそうなってんの?」って思うかもだけど、そうなってるんです地球。ぐるぐる回ってるんで。


じゃあ、どうすればズレないの?

いくつか選択肢はあります。でも、どれも完璧ではありません。

① ユーザーのローカルタイムで保存

→ 保存時点のタイムゾーンで記録。本人にはズレないけど、他のタイムゾーンで見るとズレる。

② UTCで保存して、表示時にローカル変換

→ 一番よく使われる方法(Googleカレンダーとか)。でも他のタイムゾーンから見ると、誕生日が“前夜祭”になるかも。

③ 時間を持たない「日付」だけで保存

→ 理想的に見えるけど、内部処理がめんどい。APIとかDBが「時間ないと困る〜」って泣き出す。


終日予定、ちゃんと扱うには?

ポイント

ズレる前提で設計しろ!

ユーザーに「終日がズレるなんて知らなかった!」って思わせないUIや説明を入れるのが大事だと思います。

たとえば:

  • 「この予定は◯◯さんのタイムゾーン(PDT)で設定されています」と表示
  • 同じ終日予定でも、他タイムゾーンの人に見せるときは“その人の今日”に変換
  • もしくは「終日予定はあなたのタイムゾーンに合わせて表示されます」と事前に伝える

まとめ:世界は広い。時差はややこしい。

スケジュールアプリ開発、見た目以上に奥が深いです。
終日予定のズレで「あれ?」と思ったら、それは地球が悪いんです。あなたのコードは悪くない。

でもユーザーはそんなこと知らないので、ちゃんと丁寧に、気づかれないように設計しましょう。
それが世界に優しいアプリ開発ってもんです。

Discussion