回答編集履歴
1
追記: tz database
test
CHANGED
@@ -1,8 +1,8 @@
|
|
1
1
|
全ての時刻を、単一の、共通の時間帯による時刻で管理するべきだと思います。そうすれば時刻差の計算に問題はありません。
|
2
2
|
|
3
|
-
ただし、これではユーザにとっては不便なので、ユーザインタフェースでの表示の際は、その都度現地の時間帯の時刻に変換して表示します。ユーザが日時を入力したときも、現地の時間帯の表示から選択・入力させても内部的には共通の時間帯による時刻を保存します。
|
3
|
+
ただし、これではユーザにとっては不便なので、ユーザインタフェースでの表示の際は、その都度現地の時間帯の時刻に変換して表示します。ユーザが日時を入力したときも、現地の時間帯の表示から選択・入力させても内部的には共通の時間帯による時刻を保存します (Javaも[IANA Time Zone Database](https://ja.wikipedia.org/wiki/Tz_database)に対応していますから、時間帯を元に、夏時間を考慮した現地時刻への変換ができます)。
|
4
4
|
|
5
|
-
共通の時間帯としては[UTC](https://ja.wikipedia.org/wiki/%E5%8D%94%E5%AE%9A%E4%B8%96%E7%95%8C%E6%99%82)を採用することが多いと思いますが、論理的には他の時間帯 (たとえば[JST](https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E6%A8%99%E6%BA%96%E6%99%82)) を採用しても特に問題はありません。
|
5
|
+
なお、共通の時間帯としては[UTC](https://ja.wikipedia.org/wiki/%E5%8D%94%E5%AE%9A%E4%B8%96%E7%95%8C%E6%99%82)を採用することが多いと思いますが、論理的には他の時間帯 (たとえば[JST](https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E6%A8%99%E6%BA%96%E6%99%82)) を採用しても特に問題はありません。
|
6
6
|
|
7
7
|
逆に、各地の時間帯の時刻で管理する方式だと、時刻の同時性が不明確になるのはもちろん、時刻差の計算が複雑になります (特に、夏時間の開始や終了の時点をまたぐ場合が超面倒です)。
|
8
8
|
|