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

奇怪的年份3192出现了，因为不推荐使用 Date的构造函数假定您使用的是具有0含义的 2 位数年份1900。它添加1900到年份编号。

时区的差异不是Date构造函数的错。您的代码TimeZone.getTimeZone("Asia/Calcutta")用于获取时区。如果该方法无法识别时区字符串，则记录为返回 GMT 时区。看起来 Sun 在 Java 1.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;
    }

总之，您的代码在两个方面被破坏：

  • 它正在使用已弃用的构造函数。
  • 假设它将理解getTimeZone您的所有时区字符串，而 Java 1.5 显然不是这种情况。
于 2012-05-07T12:10:25.327 回答