受け入れられた答えは正しいです。java.util.Date クラスにはタイム ゾーンが割り当てられていません†</sup> が、toString
その実装では紛らわしく、JVM の現在のデフォルト タイム ゾーンが適用されます。
java.util.Date と .Calendar を避ける
これは、Java にバンドルされていることで悪名高い java.util.Date、.Calendar、および SimpleDateFormat クラスを回避する多くの理由の 1 つです。それらを避けてください。代わりに次のいずれかを使用します。
Joda-Time
Joda-Time 2.3 のコード例を次に示します。さらに多くの例と議論については、StackOveflow を検索してください。
DateTimeZone timeZoneLondon = DateTimeZone.forID( "Europe/London" );
DateTimeZone timeZoneAthens = DateTimeZone.forID( "Europe/Athens" );
DateTime nowLondon = DateTime.now( timeZoneLondon );
DateTime nowAthens = nowLondon.withZone( timeZoneAthens );
DateTime nowUtc = nowLondon.withZone( DateTimeZone.UTC );
java.time
Java 8 以降には、新しいjava.time パッケージが組み込まれています。このパッケージは Joda-Time に触発されました。これらはいくつかの類似点とクラス名を共有していますが、異なっています。それぞれに他にない機能があります。注目すべき違いの 1 つは、java.time がコンストラクターを回避し、代わりに静的インスタンス化メソッドを使用することです。
この質問の場合、それらは同じように機能します。タイム ゾーンを指定し、現在の時刻を取得するメソッドを呼び出してnow
から、古い不変インスタンスに基づいて新しいインスタンスを作成し、タイム ゾーンを調整します。
2 つの異なるタイム ゾーン クラスに注意してください。1 つは名前付きのタイム ゾーンで、夏時間やその他の異常に関するすべての規則と UTC からのオフセットが含まれていますが、もう 1 つはオフセットのみです。
ZoneId zoneMontréal = ZoneId.of("America/Montreal");
ZonedDateTime nowMontréal = ZonedDateTime.now ( zoneMontréal );
ZoneId zoneTokyo = ZoneId.of("Asia/Tokyo");
ZonedDateTime nowTokyo = nowMontréal.withZoneSameInstant( zoneTokyo );
ZonedDateTime nowUtc = nowMontréal.withZoneSameInstant( ZoneOffset.UTC );
†</sup>実際には、java.util.Date
クラスのソース コードにタイム ゾーンが埋め込まれています。ただし、このクラスでは、ほとんどの場合、そのタイム ゾーンは無視されます。そのため、簡単に言うと、juDate にはタイム ゾーンが割り当てられていないとよく言われます。混乱しますか?はい。juDate の混乱を避け、Joda-Time や java.time を使用してください。