マッチングサイトにおけるサマータイムの計算 (Java APIなど)

Question

日本と海外のマッチングサイトを作ろうとしているのですが、課題に直面してしまいました。

サイト登録時にそれぞれのいる時間帯（例えば、日本と、米国東海岸）をユーザーIDにSQL上で登録して、登録した時間帯に時間を付与し(東京ならUTC+XX時間、東海岸ならUTC+XX時間など)、マッチング時はその登録に基づいて異なる場所にいる人同士の時差を差し引きして計算するのですが、アメリカではサマータイムが存在することをすっかり考慮するのを忘れていました。

調べると世界では1/3の国が異なる時期にサマータイムを導入しているようで、アメリカ以外も含めると、差し引きの計算が大変になりそうです・・・。

Java Date and Time APIなどがあると聞いたのですが、似たように日本と海外の時間帯で面談日時をマッチングさせるケースでは、どのようなロジックでサービス構築されましたでしょうか。

Answer 1

素朴な疑問ですが、「夏時間の日」と「夏時間ではない日」の切り替わりはどうなるのでしょうか。

例えば、「夏時間ではない日」の23:59から1分後に「夏時間の日」の1:00が始まる状況が考えられます。
これはまだ良い方で「夏時間ではない日」の23:59から1分後に「夏時間の日」の-1:00が始まる状況もあり得ますが、表記しようがない日時に思えます。
空白の1時間だけはGMT+HH:mmで表記すると、0:00～0:59は「夏時間ではない日」で1:00から「夏時間の日」の0:00が始まるという時間の遡りが発生して大変分かりづらい気がします。
この辺りを上手く解決するようにコードを組まないと思わぬバグを生みかねないと思います。
いずれにしても夏時間か否かをユーザにはっきりと分かる形で表記する必要がありますね。

夏時間制は仕事の為のローカルルールなので公共の場であるWebサイトで夏時間制を導入する事がアメリカ人に浸透しているのか、は気になります。
Webサイト上で夏時間制で表記する事がアメリカ人にとって常識ならいいのですが、それが逆ならアメリカ人が標準日時だと思い込んで夏時間との時差を計算してしまい、親切で行った夏時間表記が逆に混乱を呼び起こす可能性があります。

Re: arare17 さん

Comments

[ikedas]

think49さんがおっしゃっているようなことは実際に起きます。が、たいていの地域では日付の変わり目ではなく、若干ずらした時刻に夏時間・冬時間の切り替えを行います。

たとえば中央ヨーロッパ時間では今年、3月27日01:59の1分後から夏時間が始まり、03:00になりました。2時台の時刻は存在しません。また、10月30日02:59の1分後に夏時間が終り、再び02:00になりました。2時台の時刻に2種類の解釈がありえます。

なお、夏時間はほとんどの場合は法定のものですので、それが施行されている地域 (たとえば米国インディアナ州全域) では日常の時刻表示です。また欧米などでは、地続きの地域に別の時間帯が施行されているということ自体が常識なので、時間帯を明記してあれば時刻をまちがえることはないでしょう。

[tacsheaven]

通常の標準時と夏時間適用時ではタイムゾーンの略称が異なるので、それみれば重複する時刻であっても、どっちで解釈するべきかは判断できますかね。
例：東部標準時（EST）と東部夏時間（EDT）

[think49]

To: ikedasさん、tacsheavenさん
なるほど。夏時間にもタイムゾーンの略称があってそれで区別するものなのですね。
勉強になりました。

Answer 2

DB 上に UTC+ の形で記載するのではなく、TimeZoneID の形で記載しておけばよいのではないでしょうか。
そうすれば java.util.TimeZone で、「指定した年月日は夏時間適用中か否か」を判断してくれるので、getOffset() した結果をそのまま使って計算できますから。

Comments

[arare000]

ありがとうございます！！なるほどですね。ちょっと調べてみます！

Answer 3

全ての時刻を、単一の、共通の時間帯による時刻で管理するべきだと思います。そうすれば時刻差の計算に問題はありません。

ただし、これではユーザにとっては不便なので、ユーザインタフェースでの表示の際は、その都度現地の時間帯の時刻に変換して表示します。ユーザが日時を入力したときも、現地の時間帯の表示から選択・入力させても内部的には共通の時間帯による時刻を保存します (JavaもIANA Time Zone Databaseに対応していますから、時間帯を元に、夏時間を考慮した現地時刻への変換ができます)。

なお、共通の時間帯としてはUTCを採用することが多いと思いますが、論理的には他の時間帯 (たとえばJST) を採用しても特に問題はありません。

逆に、各地の時間帯の時刻で管理する方式だと、時刻の同時性が不明確になるのはもちろん、時刻差の計算が複雑になります (特に、夏時間の開始や終了の時点をまたぐ場合が超面倒です)。

---

実際にこういう改修ができるかどうかは別問題として、まっさらから作れるとしたら、ということで回答しました。