なぜこれらの2回の減算（1927年）が奇妙な結果をもたらすのですか？

次のプログラムを実行すると、2つの日付文字列を1秒間隔で参照して解析し、それらを比較します。

public static void main(String[] args) throws ParseException {
    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");  
    String str3 = "1927-12-31 23:54:07";  
    String str4 = "1927-12-31 23:54:08";  
    Date sDt3 = sf.parse(str3);  
    Date sDt4 = sf.parse(str4);  
    long ld3 = sDt3.getTime() /1000;  
    long ld4 = sDt4.getTime() /1000;
    System.out.println(ld4-ld3);
}

出力は次のとおりです。

353

（時間の1秒の差から予想されるように）なぜそうではld4-ld3ないのですか？1353

日付を1秒後に変更する場合：

String str3 = "1927-12-31 23:54:08";  
String str4 = "1927-12-31 23:54:09";  

その後にld4-ld3なります1。

Javaバージョン：

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Dynamic Code Evolution Client VM (build 0.2-b02-internal, 19.0-b04-internal, mixed mode)

Timezone(`TimeZone.getDefault()`):

sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]

Locale(Locale.getDefault()): zh_CN

上海での12月31日のタイムゾーンの変更です。

上海での1927年の詳細については、このページを参照してください。基本的に1927年の終わりの真夜中に、時計は5分52秒戻りました。したがって、「1927-12-31 23:54:08」は実際には2回発生し、Javaがそのローカル日付/時刻の可能な限り遅い時刻として解析しているように見えます-したがって、違いがあります。

タイムゾーンのしばしば奇妙で素晴らしい世界のちょうど別のエピソード。

編集：プレスを止めて！歴史の変化...

TZDBのバージョン2013aで再構築した場合、元の質問はまったく同じ動作を示しません。2013aでは、結果は358秒で、遷移時間は23:54:08ではなく23:54:03になります。

野田タイムでユニットテストの形でこのような質問を収集しているため、これに気づきました。テストは変更されましたが、表示されるだけです。履歴データでさえ安全ではありません。

編集：歴史は再び変わりました...

TZDB 2014fでは、変更の時間は1900-12-31に移動し、現在は343秒の変更にすぎません（つまり、との間の時間はt、t+1意味がわかると344秒です）。

編集： 1900年の移行に関する質問に答えるために... Javaタイムゾーン実装はすべてのタイムゾーンを1900 UTCの開始前の任意の瞬間の標準時間にあるものとして扱うように見えます：

import java.util.TimeZone;

public class Test {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
                System.out.println(id);
            }
        }
    }
}

上記のコードでは、Windowsマシンで出力が生成されません。したがって、1900年の初めに標準以外のオフセットを持つタイムゾーンは、それを遷移としてカウントします。TZDB自体にはそれより前に遡るデータがあり、「固定された」標準時間（これはgetRawOffset有効な概念であると想定されている）の概念に依存していないため、他のライブラリはこの人為的な移行を導入する必要がありません。

現地時間の不連続が発生しました：

1928年1月1日、日曜日に現地標準時が近づいているとき、00：00：00時計は31：土曜日に0:05:52時間逆になりました。代わりに1927年12月23:54:08現地標準時

これは特に奇妙なことではなく、政治的または行政的措置のためにタイムゾーンが切り替えられたり変更されたりしたため、いつでもかなりどこでも起こっていました。

この奇妙さの教訓は次のとおりです。

• 可能な限り、UTCの日付と時刻を使用してください。
• 日付または時刻をUTCで表示できない場合は、常にタイムゾーンを指定してください。
• UTCで入力日時を要求できない場合は、明示的に示されたタイムゾーンが必要です。

時間をインクリメントするときは、UTCに変換してから、加算または減算する必要があります。表示には現地時間のみを使用してください。

この方法で、数時間または数分が2回発生する期間を歩くことができます。

UTCに変換した場合は、毎秒追加し、現地時間に変換して表示します。あなたは11時54分08秒午後通過するでしょうLMT -午後11:59:59 LMT、その後、11時54分08秒午後CST -午後11:59:59 CST。

各日付を変換する代わりに、次のコードを使用できます。

long difference = (sDt4.getTime() - sDt3.getTime()) / 1000;
System.out.println(difference);

そして、結果が次のようになることを確認します。

1

申し訳ありませんが、時間の不連続が少し進んでいます

2年前のJDK 6、そして最近のアップデート25のJDK 7。

学ぶべき教訓：表示のためを除いて、UTC以外の時間は絶対に避けてください。

他の人が説明したように、そこには時間の不連続があります。1927-12-31 23:54:08at Asia/Shanghaiには2つの可能なタイムゾーンオフセットがありますが、のオフセットは1つだけです1927-12-31 23:54:07。したがって、使用されるオフセットに応じて、1秒の差または5分53秒の差があります。

通常の1時間の夏時間（夏時間）の代わりに、このオフセットのわずかなシフトにより、問題が少しわかりにくくなります。

タイムゾーンデータベースの2013aの更新により、この不連続性が数秒早く移動しましたが、その影響はまだ観察可能です。

java.timeJava 8 の新しいパッケージは、これをより明確に見て、それを処理するためのツールを提供します。与えられた：

DateTimeFormatterBuilder dtfb = new DateTimeFormatterBuilder();
dtfb.append(DateTimeFormatter.ISO_LOCAL_DATE);
dtfb.appendLiteral(' ');
dtfb.append(DateTimeFormatter.ISO_LOCAL_TIME);
DateTimeFormatter dtf = dtfb.toFormatter();
ZoneId shanghai = ZoneId.of("Asia/Shanghai");

String str3 = "1927-12-31 23:54:07";  
String str4 = "1927-12-31 23:54:08";  

ZonedDateTime zdt3 = LocalDateTime.parse(str3, dtf).atZone(shanghai);
ZonedDateTime zdt4 = LocalDateTime.parse(str4, dtf).atZone(shanghai);

Duration durationAtEarlierOffset = Duration.between(zdt3.withEarlierOffsetAtOverlap(), zdt4.withEarlierOffsetAtOverlap());

Duration durationAtLaterOffset = Duration.between(zdt3.withLaterOffsetAtOverlap(), zdt4.withLaterOffsetAtOverlap());

その後durationAtEarlierOffsetは1秒、durationAtLaterOffset5分53秒になります。

また、これらの2つのオフセットは同じです。

// Both have offsets +08:05:52
ZoneOffset zo3Earlier = zdt3.withEarlierOffsetAtOverlap().getOffset();
ZoneOffset zo3Later = zdt3.withLaterOffsetAtOverlap().getOffset();

しかし、これら2つは異なります。

// +08:05:52
ZoneOffset zo4Earlier = zdt4.withEarlierOffsetAtOverlap().getOffset();

// +08:00
ZoneOffset zo4Later = zdt4.withLaterOffsetAtOverlap().getOffset();

同じ問題がと比較1927-12-31 23:59:59してわかりますが1928-01-01 00:00:00、この場合、より長い発散を生じるのはより早いオフセットであり、2つの可能なオフセットがあるのはより早い日付です。

これにアプローチする別の方法は、進行中の移行があるかどうかを確認することです。これは次のようにして行うことができます。

// Null
ZoneOffsetTransition zot3 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

// An overlap transition
ZoneOffsetTransition zot4 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

isOverlap()とisGap()メソッドを使用することにより、その日付/時刻に有効なオフセットが複数あるオーバーラップ、またはそのゾーンIDにその日付/時刻が有効でないギャップがある遷移が遷移であるかどうかを確認できzot4ます。

これが、Java 8が広く利用可能になったとき、またはJSR 310バックポートを採用するJava 7を使用する人々がこの種の問題を処理するのに役立つことを願っています。

私見Javaでの広く暗黙的なローカリゼーションは、その単一の最大の設計上の欠陥です。それはユーザーインターフェースを対象としている可能性がありますが、率直に言って、プログラマーは対象としないため、ローカライズを基本的に無視できる一部のIDEを除いて、ユーザーインターフェースにJavaを実際に使用しています。あなたはそれを（特にLinuxサーバーで）修正することができます：

• エクスポートLC_ALL = C TZ = UTC
• システムクロックをUTCに設定する
• 絶対に必要でない限り、ローカライズされた実装を使用しないでください（つまり、表示のみ）

Javaコミュニティプロセスのメンバー私がお勧めします。

• ローカライズされたメソッドをデフォルトではありませんが、ユーザーがローカライズを明示的に要求する必要があります。
• 代わりに、UTF-8 / UTCをFIXEDのデフォルトとして使用してください。このようなスレッドを作成したい場合を除いて、他に何かをする理由はありません。

つまり、グローバル静的変数は反OOパターンではないのですか？いくつかの基本的な環境変数によって与えられるこれらの広範なデフォルトは他にありません.......

他の人が言ったように、それは1927年の上海での時間変化です。

それがだったときに23:54:07、上海、現地標準時間ではなく、5分52秒後に、それは、次の日になって00:00:00、その後、現地標準時間がに戻します23:54:08。そのため、2つの時間の差は、予想どおり1秒ではなく343秒です。

時間は、米国などの他の場所でも混乱する可能性があります。米国には夏時間があります。夏時間が始まると、時刻は1時間進みます。しかし、しばらくすると夏時間が終了し、標準時間帯に1時間戻ります。したがって、米国の時間を比較すると、違いは36001秒ではなく数秒になることがあります。

しかし、これらの2つの時間の変化には異なる点があります。後者は継続的に変化し、前者は単なる変化でした。同じ量だけ元に戻ることも、再度変わることもありませんでした。

表示のように非UTC時間を使用する必要がない限り、時間が変更されないUTCを使用することをお勧めします。