サマータイムでの時間の逆行に対応するアプローチ

シェアする

Voiced by Amazon Polly

連日オリンピックのためだけに導入されると騒がれているサマータイム。2時間も時間をずらすということで世界的にもほとんど前例がありません。
個人的にはわざわざオリンピック、いやゴミンピックのためだけに導入するのはやめてほしいのですが。さて、すでにサマータイムが導入されている地域でコンピュータを使用する場合はどのようなアプローチをとっているのでしょうか。

広告



サマータイムにより、時間のスキップや逆行が起きる

サマータイムが導入されると、時間をある一定の間ずらすことになります。したがって、ずらした瞬間に時間のスキップや逆行が起きます。米国では、一部地域を除き1時間のサマータイム(Daylight Saving Time, DST)が導入されています。
サマータイム開始時は、時計を1時間進めることになり、時間のスキップが発生します。終了時は、逆に1時間戻すことになり、時間の逆行が発生します。

逆行した時間をログ上で区別する

時間の逆行で困るのが各種ログでしょう。特に、終了時に関しては時間の逆行が発生することで、同じ時間が2回発生します。当然、この2回の同じ時間は物理的に別の時間であるために区別が必要です。

対応しない場合、同じ時間であることで防犯カメラの映像が上書きされるような問題が発生します。

米国では実際にサマータイムが導入されていますが、ログに関してはどのように対応されているのでしょうか。

タイムゾーンを記載する

協定世界時(UTC)に対するオフセットを同時に記録し、区別します。Apacheのアクセスログは、次のようになっています。
xx.xx.xx.xx - - [11/Aug/2018:05:11:00 +0900] "HEAD / HTTP/1.1" 200 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36"
この例では、+0900がタイムゾーンを示しています。日本で2時間サマータイムを導入した場合、サマータイム中は+1100となることで区別できます。
サマータイムから戻す場合は、+1100が1回目、+0900が2回目となることで区別ができます。

フラグを立てる

時刻とは別に何かしらのフラグを立てる形で対応します。1回目と2回目を区別できるような情報を、時刻とは別に記録する形で行います。

日本標準時を使うのをやめて、協定世界時で対応する

サマータイムが導入される日本標準時(JST,JDT)の使用をやめて、協定世界時(UTC)で対応します。実際に利用する場合は、アプリケーションで対応するか、運用でカバーすることで都度オフセットを確認し読み替えます。

対応は無理ではないけれども

世界レベルで対応しているアプリケーションであれば、サマータイムを導入しても軽微な変更で済むかもしれません(想定外の不具合が潜んでいる可能性はあります)。
しかし、日本国内向けに設計されているアプリケーションの場合、暗黙の了解としてUTC+9とタイムゾーンが決め打ちになっているような場合があります。そのようなアプリケーションの場合、サマータイム対応のために大規模な改修が必要になることがあります。当然、無用なトラブルを招く恐れはありますし、そう簡単に改修ができるとも限りません。
1年以内に実施しようという話が上がっていますが、無理があります。間違いなく混乱は起きるでしょう。UTC+9が日本の時刻であるという常識が破壊されるためです。

もしかすると、サマータイムにあえて対応せず「運用でカバー」するのが最も楽な手段であるかもしれません。