java.util.Date在JDK 5和JDK 6

在下面的代码当与JDK5运行返回不同的日期（1.5.0_09）打印java.util.Date在JDK 5和JDK 6

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)); 

    } 
}

来源

2012-05-07 Varun

+13

当您通过调用* deprecated *构造函数开始时，您不应该对关于不一致结果的SO报警。是的，它会导致问题，这就是它被弃用的原因。 –

使用不推荐的方法本身并不是真正的理解Java版本之间不同行为的好方法。在这种情况下，Date构造函数在两种情况下都完全相同，不同之处在于不推荐使用的TimeZone.getTimeZone方法。 – jarnbjo

奇怪一年3192正在兴起，因为弃用Date构造假设你使用的是2位数的一年0意思1900。它将1900添加到年份编号。

时区的差异并不是Date构造函数的错误。您的代码使用TimeZone.getTimeZone("Asia/Calcutta")来获取时区。如果该方法不识别时区字符串，则该方法为documented作为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-07 12:10:25

java.util.Date在JDK 5和JDK 6

回答

相关问题