5

私のタイムゾーンは CET (ベルリン) です。
Joda の DateTime をテストしているときに、いくつかの奇妙なことに気付きました。

new DateTime(1893, 4, 1, 0, 0, 0, 0);
=>  java.lang.IllegalArgumentException: Illegal instant due to time zone offset transition: 

new DateTime(1893, 3, 31, 0, 0, 0, 0).toDate();
=>  Fri Mar 31 00:06:32 CET 1893

タイム ゾーンが 6 分 32 秒ずれて、時間が存在しなくなりますか??
タイムゾーン情報を指定していなかったため、この種の問題が発生するとは予想していなかったため、これは非常に予想外であると言わざるを得ません。
1893 年 3 月に CET (ベルリン) が存在しない場合new DateTime(1893, 3, 31, 0, 0, 0, 0)、指定した時刻 (つまり、0 分 0 秒) に一致するタイム ゾーンを選択しないのはなぜですか?

DateTime で正しい時刻を取得するためのオプションは何ですか?

-- 編集 --
問題は toDate() のようです。質問を投稿する前に編集しました。
Joda 自体は実際には問題なく動作します。

new DateTime(1893, 3, 31, 0, 0, 0, 0);
=>  1893-01-01T00:00:00.000+00:53:28

Date への変換によって、オフセットの一部が分と秒に移動されるだけです。

4

2 に答える 2

10

タイムゾーンを指定しない場合、残念ながら Joda Time はシステムのものを使用します。そして、そうです、ベルリンはその時 (そして 6 分 32 秒まで) に本当に変化しました。つまり、存在しない現地時間を指定していました。

「指定した時間に一致するタイム ゾーンが [...] 選択されないのはなぜですか?」とはどういう意味ですか? - タイムゾーンは、現地時間が UTC にどのようにマッピングされるかに影響します。暗黙的に指定したタイムゾーン（システムのデフォルトを選択させることにより）には、その時間が存在しませんでした。そのローカル時間に UTC インスタント マップはありません。その現地時間をマッピングするタイム ゾーンはいくつもあります。

システムの既定のタイム ゾーンを使用することは Joda 側の悪い動き (およびNoda Timeで修正したもの) であることに同意しますが、残りの動作はすべてまったく問題ありません。(Noda Time では、明らかに悪い値を渡すことと区別するために、まさにこの状況に対して特定の例外がありますが、ここまでです。)

タイムゾーンをまったく入れたくない場合は、代わりにa を使用する必要がありますLocalDateTime。

于 2010-03-10T21:08:03.320 に答える
0

でアイテムをインスタンス化しようとしましたnew DateTime(1893, 4, 1, 0, 0, 0, 0, DateTimeZone.UTC);か?

于 2010-03-10T21:09:06.460 に答える