关于java.util.Date的时间的问题

今天在做项目的时候意外的发现关于时间显示出错的问题。总的来说，就是我获得new Date()这个对象的时候，当前的时间比系统时间足足少了8个小时。我感到莫名其妙，当前一般获得系统时间的时候，一般都是采用Date date = new Date()；这个方法来获得当前时间的，那是什么原因造成的使用问题呢。。 我仔细的跟进了下执行代码，发现了我以前的项目中为了发送消息的时候获得了当前的时间毫秒数。效果如下

		TimeZone tz = TimeZone.getTimeZone("ETC/GMT");
		TimeZone.setDefault(tz);
		int time = (int) (new Date().getTime() / 1000);

然后我又打印了下系统当时的显示时间即 System.out.println(new Date())，打印结果显示如下：Fri May 25 05:57:03 GMT+00:00 2012 。然后我又打印了默认当前时间的显示结果如下：Fri May 25 13:57:02 CST 2012。我大概就猜测到了问题的所在了，这个setDefault()方法是可以设置默认的时区效果的，而且设置效果还是 全局性的系统时区。

接着我又开始查询了下Date date = new Date()的源码

    public Date() {
        this(System.currentTimeMillis());
    }

    public Date(long date) {
        fastTime = date;
    }

这个System.currentTimeMillis()，经查询是个native的方法，这表示该方法调用了JVM相关的C++方法代码，具体的实现我就没有仔细的去查看了。然后我就去网上查阅了相关的资料，网上的意见是，JRE下面有个GMT的时间配置文件，JVM运行的时候正是加载了这个配置文件参数来获得当前时区的，这样的话，心里就有个大概的思路了。System.currentTimeMillis()到底做了什么呢。我猜想应该就是直接获得的是当前系统的时间(注：此时间应该是没有时区的世界时间),由于java的某些特性，无法与底层的系统硬件的某些参数，该方法只能通过native的C++方法来实现，当获得了当前的系统时间了以后，然后在显示的时间了的时候加载了时区参数即TimeZone来调整了时区的显示。为了验证我的这个想法，我先写了个测试用例代码如下：

		int time1 = (int) (new Date().getTime() / 1000);
		System.out.println(time1);
		System.out.println(new Date());
		TimeZone tz = TimeZone.getTimeZone("ETC/GMT");
		TimeZone.setDefault(tz);
		int time = (int) (new Date().getTime() / 1000);
		System.out.println(time);
		System.out.println(new Date());
		TimeZone tz1 = TimeZone.getTimeZone("ETC/GMT-8");
		TimeZone.setDefault(tz1);
		int time2 = (int) (new Date().getTime() / 1000);
		System.out.println(time2);
		System.out.println(new Date());

由于默认使用的是GST时间格式，而我们的时区是在GMT-8时区，那么当TimeZone使用GMT时间格式的时候，则最终的显示时间将会少于8小时。然后我有查询了下getTime()方法，此方法调用了一个fina属性的getTimeImpl()方法，而getTimeImpl()方法里面有判断了一个cdate的BaseCalendar.Date对象是否为空，我们的这个例子中没有初始化cdate方法，则可以不理，也就是说，getTime()方法应该是显示的系统时间的毫秒数。那么最终的显示时间应该是这三个的time应该是一致的，但是打印出来的时间格式Date1和Date3显示的时间应该是一致的，但是分别应该是GST和GMT-8的时区格式，Date2的时间则会少8个小时。执行的结果如下：

1337925422
Fri May 25 13:57:02 CST 2012
1337925423
Fri May 25 05:57:03 GMT+00:00 2012
1337925423
Fri May 25 13:57:03 GMT+08:00 2012

现在Date的问题应该是明朗了，在这个Date方法里面关于时区的认定也太不够通用了，与java设计过程高内聚低耦合完全不符，Date的很多实现严重依赖TimeZone的类实现。如果我要实现临时切换时区的时候，则会非常马上，得去TimeZone里面去把默认时区给修改了，然后在来使用...联想起以前从JDK1.5的时候开始，SUN公司就已经推出了个新的日期类库Calendar，而与此同时Date里面的绝大多数方法都已经被标记为不推荐了，我当时还很奇怪，现在我重新查看了下Calendar中的方法，其使用工厂方法的形式不光提供了默认的时区方式的实现，也提供了Calendar.getInstance(zone)的实现。这样最大化程度的满足了用户对时间方法选择的需求。