問題タブ [jsr310]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
286 参照

java - RFC 3339 日時の解析時にゾーン調整が考慮されない

( CodeReviewから移行)

私は実験を行い、Java Time をよりよく理解しようとしています。JSR-310 のタイム ゾーンの処理について、私の側で誤解が生じている可能性があります。

解析するタイムスタンプ文字列がありますDateTimeFormatter

上記の値は、サーバーの現地時間が中央ヨーロッパの午前 10 時 39 分であるときに生成されます。夏時間のため、UTC 時間は午前 8 時 39 分です。独自の計算を行って、自分のゾーンにいる時間を見つけることができます。

次のテストは、コンピューターのタイム ゾーンがタイムスタンプ (+2) に表示されているものと同じ場合に機能します。

Java Time がタイムゾーンを調整する方法をよりよく理解するために、入力文字列をいじってみまし。しかし、結果は驚くほど間違っています!

テストが失敗するように、入力文字列のタイムゾーンを繰り返し変更しようとしました。たとえば、文字列を次のように変更する2019-08-28T10:39:57+08:00と、パリの午前 2 時を意味します。しかし、上記のテスト コードは、時刻をチェックするときに引き続きパスします。つまり、結果LocalDateTimeの時刻はまだ午前 10 時です。

質問

ソース文字列のタイムゾーンを常に変更しているにもかかわらず、コードが現地時間として 10 を返すのはなぜですか?

LocalDateTime次に、RFC 3339 文字列 (埋め込まれたオフセットの瞬間を表す) を解析し、可能なゾーン調整に関してオブジェクトに変換する正しい方法は何ですか? マシンが CE[S]T タイム ゾーンで実行されているとします。

環境

タイムスタンプをコンピューターの時刻と比較して、古すぎないかどうかを確認する必要があります。つまり、米国の時間がヨーロッパで評価される場合、それは「古すぎる」可能性はありません。