が、それはここだけで23時間の代わりに24

Question

を追加するサンプルコード

public class DateFormatSampleCode { 
    public static void main(String[] args) throws ParseException { 
     DateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ"); 
     Calendar cal = Calendar.getInstance(); 
     cal.setTimeZone(TimeZone.getTimeZone("America/Los_Angeles")); 
     cal.setTime(sdf.parse("2016-03-12T02:00:00-0800")); 
     sdf.setTimeZone(TimeZone.getTimeZone("America/Los_Angeles")); 
     System.out.println(sdf.format(cal.getTime())); 
     cal.add(Calendar.DATE, 1); 
     System.out.println(sdf.format(cal.getTime())); 
    } 
} 

はここで回答

「2016から03です-12T01：00：00" から0800

が、私の視点から、それがあるべき」

2016-03-12T03：00：00-0700

"となります。

Answer 1

「2016年に夏時間（DST）は、2016年3月13日午前2時（現地時間）から2016年11月6日午前2時（現地時間）」（https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst）まで有効です。したがって、午前2時に3月12日に24時間を追加すると、時計が2時から3時に前方に移動した時刻が正確に表示されます。だから私は、結果が何であるかははっきりしているとは思わない。私はすぐに02:00:00-0800または03:00:00-0700のいずれかを期待します（後者はあなたが期待したものです）。

pre-Java-8 Calendarクラスを使用しています。結果が正確に文書化されていれば、私はそれを逃してしまった。文書には、追加は「カレンダーのルールに基づいている」としか書かれていません。それについて考えてみると、3月12日の2時から3時の間に開始すると、何が予想されるのでしょうか？2日前には、24時間後の3月13日に同じ時刻になります。 3日後も簡単ですが、同じ時間になるだけです。変更のために23時間後です。 2と3の間の時間は、同じ時間が3月13日に存在しないので、選択する必要があります。 1時間を引くことが選択されたようだ。彼らはさらに、午前2時にこれを行うことを選択しましたが、3時半ではなく、1時間の半開き期間にルールを有効にしました。少なくともそれは一貫しています。おそらく予期しない結果を完全に避けることはできません。

例えば、ZonedDateTimeのようなJava 8 java.timeクラスは、よりよく文書化され、したがってより信頼性が高くなります。 ZonedDateTime.plusDays()は、たとえば、日時を現地の日時に加算し、ZonedDateTimeに変換し直します。地方の日時がギャップにある場合（ここのように）、ギャップの長さで前方調整されます（ここでは1時間）。結果は期待どおり正確に2016-03-13T03:00-07:00[America/Los_Angeles]になります。学ぶため

一つの可能​​な教訓は、Java 8.場合は、一日追加した後でタイムゾーンを再設定は何