» » サマータイムの影響って結構深刻
2018/08/08

8/08/2018

サマータイムの影響って

このところ数日間サマータイムの話題が飛び交っているので、個人的に把握してみました。

Javaのランタイムなどは専門外なので、他のサイトを見てもらえるとよろしいかと。

ここではもっと一般的なものと、巷で実施されいるコードについて記載して見ます。

現代の日付（時刻）管理（前提知識）

現代の日付は以下の管理方式になっています。

  • 地域日付(時刻) →　UTC変換 全世界共通時刻
  • 地域日付(時刻) ←　UTC変換 全世界共通時刻

日本の場合、UTCに9時間を加算して地域日付（時刻）にしています。(JST-9)

UTC (フランス 原子測定器によるもの　うるう秒とかある)≒ GMT(イギリス天文学的時刻 昔はこれ）

※重要

地域日付(時刻)は地域によっていろいろと補正しないといけないので、基礎値として管理せず、全世界共通のUTCに変換して管理する。

これにより、時間が明確に管理できるようになる。（UTCを参照するときにその地域の日付時刻に変換すれば良いから)

サマータイム

一般知識としてのサマータイムは「Qサマータイムってどういう意味なの？何か注意は必要？ 」に解説がありました。

内容見ますと、開始時点では時刻が先送りし、終了時には戻されるという動きとなります。

これを前提に、少々例を考えてみます。2019/5/1 23:00から、2019/6/30 23:00まで2時間のサマータイムがあるとして例を記載してみます。

  • (1)開始の状況
    • UTC JST-9(既存) JST-9(サマータイム)
    2019/05/01 13:59:59 2019/05/01 22:59:59 2019/05/01 22:59:59
    2019/05/01 14:00:00 2019/05/01 23:00:00 2019/05/02 01:00:00(2H飛び)

    JST-9(サマータイム)では2019/05/01 23:00～ 2019/5/2 0:59 の時刻は存在しないことになります。

  • (2)終期の状況
    • UTC JST-9(既存) JST-9(サマータイム)
    2019/06/30 11:59:59 2019/06/30 20:59:59 2019/06/30 22:59:59
    2019/06/30 12:00:00 2019/06/30 21:00:00 2019/06/30 21:00:00(2H戻る)

    JST-9(サマータイム)の2019/06/30 21:00～2019/6/30 22:59:59とJST(既存)に重複時刻が出てきます。

    もっと詳細に書くと、以下のとおり。

    UTC JST-9(既存) JST-9(サマータイム)
    2019/06/30 10:00:002019/06/30 19:00:002019/06/30 21:00:00
    :::
    2019/06/30 11:59:592019/06/30 20:59:592019/06/30 22:59:59
    2019/06/30 12:00:002019/06/30 21:00:00←サマータイム終了既存時刻既存時間に戻る
    :::
    2019/06/30 13:59:592019/06/30 22:59:59

    これ大変です。！！

    • 2019/06/30 22:59:59 だけ見ただけでは、サマータイムの時刻か、既存の時刻かわからない。
      • →値不明確
    • 2019/06/30 22:59:59 サマータイムの１秒先が2019/06/30 21:00:00既存だが、単純文字列比較では、前者が後の時間に評価される。
      • →値の逆転

影響を考えてみる

日付時刻を地域時間に変換して記録しているすべてに、サマータイム終期に時刻の前後関係がずれてしまう可能性がある。

  • ログに記録している日付時刻に関係？

    • ログは重要ですが、処理の根幹にはかかわらないので、まあ努力目標としてごまかすこともできるかもしれません。

  • データキーの日付時刻

    • データを時系列管理するために、データのキーに日付時刻を付与する例がありますが、日付型ではなく、地域日付時刻の文字列に変換した値を管理している場合、サマータイムの終期に時刻戻りや重複が発生するため、時系列管理や一意性が失われしまう。

    データ管理の根幹に関わる問題に発展します。データベースの場合は日付型に型変換する必要があります。これは大変です。

和暦改正どころではない深刻な影響があること個人的にもびっくりしています。

VB6.0のFormat(Now(),"YYYY/MM/DD HH:NN")なんかも影響受けるでしょうね。

改善策

次の３点を考えました。他にもあるかもしれませんが、対処するには時間が掛かりそうですね。

  • (1)内部管理をすべてUTCにする。

    • それができれば苦労しないとの声が聞こえてきそうです。

  • (2)内部管理を既存日付時刻とする。

    • 日本と韓国は同じ9時間エリアなので、TZをKST-9で動作させればサマータイムを迂回して、維持できるとおもいます。

  • (3)黙認する。

    • 座して死を待つ状態ですね。最終手段ということで。

影響範囲を事前に進言して、予算を確保してもらうなど、業界にいる者としては、できることをしていきたいと思うところです。

こんな誰も得をしないことなんでするのかなぁと思いつつ。思いとどまってくれないかなぁ。

その後の追記

なんと、みんな大好きExcelは、そもそもタイムゾーンの概念が無いそうです。

まあ、ありそうな話ですが、同じシートを使って世界流通させることなんて考えていなかったんでしょうねぇ。

ラベル:

0 コメント:

コメントを投稿

登録: コメントの投稿 (Atom)