3

日付を解析しようとしていますが、コードをローカルで実行すると異なる結果が得られます/BST は、パリ/CEST のサーバーと比較します。

次のサンプルで問題を再現しました。これは、オーストラリア グランプリの開始日を解析しようとしています。

    TimeZone tz = TimeZone.getTimeZone("AET");
    DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy HH mm");
    dateFormat.setTimeZone(tz);
    long time = dateFormat.parse("28/03/2010 17 00").getTime();
    System.out.println("Time "+time);

日付形式でタイムゾーンを正しく設定しているようで、現在のタイムゾーンがコードに影響を与えるべきではありません。しかし、ローカルでは 1269756000000、パリでは 1269759600000 と出力されます。

答え：

エッジケースでテストしていたようです.Linuxサーバーと比較して、私のMacではタイムゾーンの定義が異なります。タイムゾーンを「America/Los_Angeles」に変更すると、一貫した結果が得られます。間違った結果をもたらす Linux ボックスは、古い可能性がある Java 1.6.0-b105 を実行しています。アップグレードしてみます

4

2 に答える 2

2

面白い。ドキュメントによるとTimeZone：

3文字のタイムゾーンIDJDK1.1.xとの互換性のために、他の3文字のタイムゾーンID（ "PST"、 "CTT"、 "AST"など）もサポートされています。ただし、同じ略語が複数のタイムゾーンで使用されることが多いため（たとえば、「CST」は米国の中部標準時と「中国標準時」の場合があります）、Javaプラットフォームは次のいずれかのみを認識できるため、これらの使用は非推奨になります。彼ら。

「AET」の代わりに「オーストラリア/メルボルン」を使用した場合の結果を確認するのは興味深いことですが、私が行った簡単な実験からは、違いはないようです。

いずれかのケースで夏時間が考慮されていないように、結果が1時間離れているのは不思議です。ばかげた質問; 2台の別々のコンピューターで実行している場合、それぞれの時刻が正しく設定されていることを確認しますか？

于 2010-03-31T07:17:28.820 に答える
1

ここの私のシステムでは、結果は「1269756000000」です（ローカルシステムと同様）。パリのサーバー、特にタイムゾーンに関する設定を確認してみます。

System.out.println(System.getProperty("user.timezone"));
System.out.println(System.getProperty("user.country"));

おそらく、これにより、この問題を解決するのに役立ついくつかの違いが生じます。

于 2010-03-31T07:34:46.697 に答える