0

JDK5（1.5.0_09）で実行した場合の以下のコードは、

Fri May 03 00:00:00 GMT 3912 
5/3/12 5:30 AM

JDK6（1.6.0_23）で実行すると、

Fri May 03 00:00:00 IST 3912
5/3/12 12:00 AM

明らかに違いは、使用されるタイムゾーンが原因で、Dateオブジェクトが作成されます。しかし、これはJDKのアップグレード時に既存のコードに問題を引き起こしませんか？この動作はどこかに文書化されていますか、それとも何かが足りませんか？

    class TimeTest {

    public static void main(String[] args) {

        Date d = new Date(2012, 04, 3);
        Locale l = new Locale("en", "US","");   
        DateFormat df= DateFormat.getDateTimeInstance(DateFormat.SHORT,  DateFormat.SHORT, l );
        TimeZone t = TimeZone.getTimeZone("Asia/Calcutta");
        df.setTimeZone(t);      
        System.out.println(d);
        System.out.println(df.format(d));

    }
}
4

1 に答える 1

4

非推奨のコンストラクターは、意味のある2桁の年を使用していると想定しているため、奇妙な年3192が発生しています。年番号に追加されます。 Date019001900

Dateタイムゾーンの違いはコンストラクターのせいではありません。コードはTimeZone.getTimeZone("Asia/Calcutta")タイムゾーンを取得するために使用しています。そのメソッドは、タイムゾーン文字列を認識しない場合にGMTタイムゾーンを返すものとして文書化されています。Sunは、Java1.6でより多くのタイムゾーンのサポートを追加したようです。（ほとんどの人は、これを移植性の懸念としてではなく、良いことと見なします。）

私は試していませんが、要求されたゾーンIDが認識されない場合に、GMTを使用しないようにするには、次の方法で十分です。

    public TimeZone getZone(String id) {
        TimeZone tz = TimeZone.getTimeZone();
        if (!tz.getID().equals(id)) {
            throw new IllegalArgumentException("unrecognized zone " + id);
        }
        return tz;
    }

要約すると、コードは2つの点で壊れています。

  • 非推奨のコンストラクターを使用しています。
  • これは、すべてのタイムゾーン文字列を理解することを前提getTimeZoneとしていますが、Java1.5の場合は明らかにそうではありません。
于 2012-05-07T12:10:25.327 に答える