以下のロジックに従ってZonedDateTimeをインスタントに変換することを計画しています。
たとえば、PST timeZoneにいて、現在の時刻は午前11時です。今変換すると(2018年3月4日現在、夏時間なし)、toInstantは午後7時になります。
同じ午前11時に、夏時間調整が行われるため、2018年4月4日の時点でtoInstantは午後6時を返します。
したがって、以下のコードは正しく戻ります。
ZonedDateTime dateTime = ZonedDateTime.now(); --->>> March 04th 2018 at 11 A.M PST
dateTime.plusMonths(1).toInstant(); -->> returns April 04th 2018 at 6 PM PST as daylight saving will be observed
だが、
Instantに変換してから1か月追加すると、結果は異なります。
Instant dateTime = ZonedDateTime.now().toInstant(); --->>> March 04th 2018 at 7 P.M UTC
dateTime.plus(1,ChronoUnit.MONTHS).toInstant(); -->> returns April 04th 2018 at 7 PM UTC ( but the actual time should be 6 PM UTC ).
これは問題ありません。すでにUTCに変換し、そこから追加しています。
したがって、夏時間を含めるには、ZonedDateTimeに日、月、または年を追加してから、インスタントに変換する必要があります。
ZonedDateTime dateTime = ZonedDateTime.now(); ---> March 04th 2018 at 11A.M
dateTime.plusDays(10).toInstant(); ---> March 14th 2018 at 6P.M
dateTime.plusMonths(1).toInstant(); ---> April 04th 2018 at 6P.M
上記のコードは期待どおりに動作します。しかし、以下のものは午後6時を返していませんが、午後7時を返します。
dateTime.plusSeconds(org.joda.time.Period.days(1).multipliedBy(10).toStandardSeconds().getSeconds())
.toInstant()) --> ---> March 14th 2018 at 7P.M
よくわかりませんが、これの何が問題になっているのか、それを秒単位で機能させる方法はわかりません。
原因はZonedDateTime
クラスのドキュメントにあります。メソッドplusDays
については、メソッドのドキュメントでこれを確認します。
これはローカルのタイムラインで動作し、ローカルの日付時刻に日数を追加します。次に、ゾーンIDを使用してオフセットを取得し、ZonedDateTimeに変換して戻します。
ZonedDateTimeに変換し直すときに、ローカルの日付と時刻が重複している場合、可能であればオフセットが保持されます。それ以外の場合は、以前のオフセットが使用されます。ギャップがある場合、ローカルの日時はギャップの長さだけ前方に調整されます。
ただし、plusSeconds
メソッドのドキュメントでは次のようになっています。
これはインスタントタイムラインで動作し、1秒を追加すると常に1秒後になります。これにより、ローカルの日時が1秒以外の時間で変化する場合があります。これは、日、月、年で使用されるアプローチとは異なることに注意してください。
したがって、2つの方法は異なる動作をするように設計されており、目的に合うように使用する方法を選択するときに、これを考慮する必要があります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加