LoginSignup
10

More than 5 years have passed since last update.

ほんとうにあったサマータイムについて

Last updated at Posted at 2017-12-05

メリークリスマス。
トラブルの事例は多い方がいいということもあり、「社内の問い合わせでこんなことがあった!」という現象を共有させていただければと思います。

問い合わせの内容

弊社のシステムでは、人物についてのマスターデータを登録いただくと、会計システムや税務システムのデータを作る際に必要な情報は再入力をしないで連動が自動的に行われるようになっています。
あるとき、「マスターに登録されているデータと税務データに連動されたデータに1日ずれが発生してしまう」というお問い合わせがありました。
「ただ連動しているだけなのにずれるって事は無いよなぁ」とおもって調査をしたところ、特定の年月でだけ現象が出ているということが判明し・・・、このあたりから「あれ?」となっていきます。

発生した日は?

お問い合わせがあったマスターの登録日は
昭和26年5月11日でした。
そのデータのみ、連動を実施すると昭和26年5月10日になってしまいます。
しかし、昭和26年12月1日のデータを作成すると、そのまま正しく連動されます。
この日にはいったい何があったのだろうか?と調べてみたところ・・・

日本にもあったサマータイム

原因はサマータイムにありました。

サマータイム(夏時間)とは、特定の期間中は時計の時間を1時間ずらすして、それを基準に生活をすることです。
例えば、朝9時に出勤して18時に帰っているひとは、実際は朝10時に出勤して19時に帰ることになります。
で、サマータイムが終わったら時計の針を1時間戻します。

明るい時間を有効に活用しようって政策のようですが、これが問題でした。

時刻の変換

Javaで日付の情報を扱う際に、弊社のシステムでは年月日+時刻で取得していました。
問題の昭和26年5月11日で登録されているデータベースからは西暦変換して、
1951-5-11 00:00(日本時間)
と時刻付きのデータが生成されます。

これをJavaではサマータイム期間中ですので、内部的に1時間戻してしまいます。
そうなると、取得した際には
1951-5-10 23:00(日本時間)
となり、日付のみを表示に使っていると1日戻ってしまう現象が発生するということです。

なかなか気が付きませんでした・・・。

サマータイムの期間

このあたりの情報は、
http://d.hatena.ne.jp/nowokay/20130917
こちらのページにも詳細にありますので、より詳細に把握したい場合はご参照ください。

ちなみに日本でサマータイムに該当する期間としては以下の通りです。
昭和23年5月3日(月)~9月11日(土)
昭和24年4月4日(月)~9月10日(土)
昭和25年5月8日(月)~9月9日(土)
昭和26年5月7日(月)~9月8日(土)

日本でもいろいろな施策が過去に実施されていたのですね・・・
この件では背景も含めて勉強になりました。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10