3

レコードが作成および更新されたときにタイムスタンプを記録するサーバー側アプリケーションを実装しました。アプリは、サーバー クロックで夏時間が有効になっていないことを前提としています。(a) これがベスト プラクティスであると読んだため、(b) 発生するあいまいさを処理するのは (不可能ではないにしても) 難しいと思うためです。たとえば、10 月に時計が 1 時間戻る場合などです。

安全のため、起動時に DST が有効になっていることをアプリが検出すると、エラーがログに記録され、アプリが終了します。アプリ サーバーのクロックで DST が有効になっている場合でも、アプリケーションを動作させるように内部関係者から請願を受けています。

これは無謀なことだと思いますが、経営陣を説得する必要があります。実装がよりトリッキーになるだけなのか、それとも根本的な欠陥により、そのようなアプリ (タイムスタンプを記録する) が 1 年中いつでも 100% 正しく機能することは不可能なのでしょうか? DST を有効にしてそのようなアプリを実行しないための最良の議論は何ですか?

私が思いついた最高のものは次のとおりです。

夏時間が有効になっている場合、年に 2 回の時間の不連続があります。サーバーが英国で実行されており、時計が現地時間に設定され、夏時間が有効になっている場合を考えてみましょう。
  • 2009 年 10 月 25 日の午前 2 時に、時計は 1 時間戻り午前 1 時になります。
  • レコードは午前 1 時 30 分に作成されます
  • アプリ (タイムスタンプを UTC で保存する必要があります) は、これが午前 1 時 30 分で、時計が戻る前か後かを判断できないため、UTC への調整に余分な時間を含めるかどうかを判断できません。

    • これは本当ですか？10 月 25 日の午前 1 時 30 分に発生するイベントが時計調整の前か後かを (Java Web アプリで) 実際に判断することは可能ですか?

    DST を回避するより良い理由はありますか?

    アップデート

    明確にするために、アプリが時刻を UTC として保存する必要があるのは当然のことです。問題は、これを実行しようとするときに、サーバー マシンで DST を有効にするのがなぜ悪い考えなのかということです。

    4

    3 に答える 3

    14

    私は (長年の悪い経験から) 日付と時刻を UTC として保存し、ユーザーが表示したい場合にのみ現地時間に変換するのが最善であることを発見しました。

    さらに、ユーザーが現地時間を入力できるようにしますが、保存する前にそれらを UTC に変換します。

    これにより、アプリケーションが複数のタイム ゾーンに分散されている場合に何が起こっているのかを理解しようとするなど、あらゆる種類の問題を回避できます。

    UTC 時刻のみを取得して保存する場合、DST は関係ありません。

    私たちが継承した特に厄介なアプリケーションの 1 つは、複数のタイムゾーンにまたがるタイムゾーンを持つ現地時間でメッセージを送信し、これらを頻繁に変更するには多大なエネルギーを費やす必要がありました。

    UTC のみを使用するように変更したところ、はるかに改善されました。一方の端での UTC への変換はできるだけ早く行われ、現地時間への変換は可能な限り最後の瞬間まで延期されました。コードは大幅に小さくなり、高速になりました。

    于 2009-10-08T13:39:06.510 に答える
    5

    タイムゾーンはフォーマットにすぎない（または「すべき」と言うべきである）ため、サーバーでDSTを禁止する理由はありません。システムクロックはタイムゾーンに依存しません。タイムスタンプは、「エポック以降のティック」System.currentTimeMillis()とその同類（タイムゾーンに依存しない）として、またはUTCオフセットが指定されたテキスト（ISO 8601のように明確になる）として、明確な形式で保存する必要があります。

    于 2009-10-08T13:46:26.403 に答える
    0

    組み込みの Java クラスを使用して日付と時刻を格納する限り、DST は問題になりません。時間の内部表現は「1970 年 1 月 1 日、イギリスのグリニッジで午前 0 時を過ぎたミリ秒」であるため、現在のタイム ゾーンや DST が有効かどうかは関係ありません。

    「10/09/2009」などのテキスト表現を使用して、2 つの日付または時刻を比較しようとしないでください。long ミリ秒値を使用します。私は現在、元の作成者が 2 つの日付を比較するたびに異なる方法を使用しているように見えるシステムに取り組んでいます。ある場所では、日付を yyyy/mm/dd として表現し、次にスラッシュを取り除き、結果を整数に変換します。つまり、2009 年 10 月 8 日は 20,091,008 になります。そして、それらを互いに比較します。また、それらをテキスト文字列として比較する場合もあります。これにより、複数のタイムゾーンまたは DST が関係している場合、いたるところで誤った結果が得られます。

    于 2009-10-08T14:00:57.950 に答える