More than 5 years have passed since last update.

サマータイム対応方法のメモ

Last updated at 2018-08-11Posted at 2018-08-11

はじめに

2020年東京オリンピックを前に、サマータイムの導入が議論され、
ITジャーナリスト（笑）が、電源切って時刻を変更するだけ・・・などという妄言を公開して大顰蹙を買ったりしています。
http://blogos.com/article/317015/

個人的にもサマータイムの導入は反対。百害あって一利なしと思っているのですが、

が気になり、調べたことをまとめます。
ツッコミ、指摘歓迎です。お気づきの事があればコメントください。

サマータイムはUTC（協定世界時）との時差を変更することで実現するのが一般的のようだ。
時刻そのものを変更するのではなく、時差をずらすことで調整する。

例えば、JST（日本標準時）は協定世界時に9時間足すことで表される。

+9時間を、夏の間だけ+11時間とすることで、時刻を2時間進める。
（電源を切ってずらしたりはしない）

以下、
(1)3/11 2:00:00からサマータイムが始まり、
(2)11/4の2:00:00にサマータイムが終わると仮定して記載する。

それぞれの時刻の変わり方は以下のようになる。

(1)3/11 1:59:59の次は3/11 4:00:00となる（2時間飛ぶ）。
(2)11/4 1:59:59の次は3/11 0:00:00となる（2時間戻る）。

タイムゾーンがいつからいつまでで、何時間ずらせばよいか、という情報は
tz databaseと呼ばれるデータに集約されているとのこと。
https://ja.wikipedia.org/wiki/Tz_database

PC・サーバ・スマートフォンともに、OSに搭載されている時計自体は、
サマータイム版のタイムゾーンを適用すれば自動的に反映されるらしい。

組み込み系でどうアップデートを適用するか・・・という問題は残るが、
OSレベルではサマータイムへの対応はそれほど問題はない(？）

思いつく限り並べてみる。

「毎日午前3時にバックアップスクリプトを起動」など。

(1)のとき、
例えば午前3時に起動する処理があった場合、
午前3時が存在しないため、実行されるはずの処理が実行されない。

(2)のとき、
例えば午前1時に起動する処理があった場合、
午前１時が１日に2回来るため、2回処理が実行されてしまう。

こういった処理の実行に使われるものとしてはcronが一般的と思う。
調べたところ、cronはそもそもサマータイムの対応ができているらしい。
https://tmotooka.hatenablog.jp/entry/2012/10/07/195622

上記の例で言えば、
(1)のときは、午前4時に午前３時に実行するはずだった処理を実行する。
(2)のときは、２回目に訪れた午前１時には、処理が実行されない。

というわけで、単にcronで定期実行している処理であれば、それほど気にしなくても良いかもしれない。

出社時刻と退勤時刻を記録し、勤務時間を計算するようなアプリケーションを考えてみる。

(1)のとき、
3/11 午前９時に出社し、3/12の午前３時（サマータイムでの午前５時）に退勤した場合、
実際の勤務時間は１８時間だが、サマータイム非対応のアプリケーションでは２０時間と計算される。

(2)のときには、逆に１６時間となってしまう。

こうした処理は以下の手順で勤務時間を計算するのが一般的と思われる。
・出社時刻と退勤時刻をそれぞれUNIX時間に変換する。
・退勤時刻のUNIX時間　－　出社時刻のUNIX時間　＝　勤務時間

サマータイムに対応させるためには、一度サマータイムを持たないUTCに変換することで対応する。
・出社時刻、退勤時刻を、UTCに変換する。
・UTCに変換した出社時刻、退勤時刻をUNIX時間に変換する。
・退勤時刻のUNIX時間　－　出社時刻のUNIX時間　＝　勤務時間

Java, Perl(DateTime::TimeZone), Python(pytz)では任意のタイムゾーンからUTCへの変換ライブラリが存在しているようである。
https://qiita.com/tinymouse/items/06706981f7bbdc8215fd

javascriptはタイムゾーン対応が甘い（？）。
https://qiita.com/tinymouse/items/06706981f7bbdc8215fd

いずれにしても、日本のサマータイムはどの言語にもまだ組み込まれていないから、自力で実装するか、言語に組み込まれるのを待ってアップグレードが必要になる。

これはかなり問題で、もしサマータイムの開始日・終了日・何日ずらすか・・・が変更されたら、その度に言語のアップデートが必要になってしまう。

もし今からアプリケーションを作るのであれば、データベース上など内部処理はなるべくUTCで持っておき、表示する際に変換したほうが良いかもしれない。そうすれば、サマータイム導入後にも変換ロジックのみの修正ですむ。

あまり他人が読んで役に立つような内容にはできませんでした。すみません。。。

以下、感想。

サマータイムはやっぱり導入すべきでない、面倒すぎる
これまでサマータイムについて意識したことはなかった。少なくとも使っている国はあるわけだから、海外展開などで気にしないといけない場合はある。その意味では良いきっかけになった。