Java永远的伤-中国1927年12月31日午夜

 

 

        话说在中国1927年12月31日午夜发生了一件神奇的事情，中国时间瞬间增加了5分52秒，

 

不管你信不信，反正我信了！不信你看下边代码！

 

/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package com.opencfg.core;

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;

/**
 * Java Date Test
 * @author opencfg.com
 * @since 0.0.1-SNAPSHOT
 * @version 0.0.1-SNAPSHOT
 * @date 2011-8-15
 */
public class JavaDateTest {

	public static void main(String[] args) throws ParseException {
		SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
		Date date1 = sf.parse("1927-12-31 23:54:06");
		Date date2 = sf.parse("1927-12-31 23:54:07");
		Date date3 = sf.parse("1927-12-31 23:54:08");
		Date date4 = sf.parse("1927-12-31 23:54:09");
		System.out.println(date2.getTime() - date1.getTime());
		System.out.println(date3.getTime() - date2.getTime());
		System.out.println(date4.getTime() - date3.getTime());
	}
	
}

 

输入结果是：

 

1000
353000
1000

 

 

5分52秒 = 5 * 60 + 53 = 352  ，在加上本来就多的1秒，结果是多了353秒

 

java傻了吗？硬件有问题吗？都错

 

是政治问题，不信你看这里：

 

附地址：http://www.timeanddate.com/worldclock/clockchange.html?n=237&year=1927

 

历史确实有记载，简单地说，在1927年末的最后那一个午夜，时钟被往回拨了5分52秒。所以“1927-12-31 23:54:08”这一秒，事实上，发生了两次，而看起来在计算当地时间时，Java将其视为了后面那一个时间点，于是就产生了这一差别。

 

下边是摘抄一iteye哥们的：

 

时间区域和JAVA 
    涉及有关时间区域信息时Java和Solaris很相似。每个时间区域都有一个时间区域ID标识符。在J2SE 1.3 and 1.4中，这个ID是个字符串，是由位于J2SE 安装程序的jre/lib子目录中的tzmappings文件这些ID列表。 J2SE 1.3 仅仅只包含tzmappings文件，但是 J2SE 1.4包含世界不同地区的时间区域数据文件。jre/lib/zi存放着这些文件。在J2SE 1.4里，sun.util.calendar.ZoneInfo从这些文件获取DST规则。在Solaris中， 这些时间区域数据文件是以二进制形式存放的，不是文本文件，因此你不能看它们。 在J2SE 1.4中的时间区域数据文件和在Solaris中是不同的。 

     java.util.TimeZone类中getDefault方法的源代码显示，它最终是会调用sun.util.calendar.ZoneInfo类的getTimeZone 方法。这个方法为需要的时间区域返回一个作为ID的String参数。这个默认的时间区域ID是从 user.timezone (system)属性那里得到。如果user.timezone没有定义，它就会尝试从user.country和java.home (System)属性来得到ID。 如果它没有成功找到一个时间区域ID，它就会使用一个"fallback" 的GMT值。换句话说， 如果它没有计算出你的时间区域ID，它将使用GMT作为你默认的时间区域。 

注意，System属性是在java.lang.System类的initProperties方法中被初始化的。这是一个本地方法。因此源代码是不可用的----除非你深入到J2SE分发包中的本地代码库中去研究。然而，在Windows系统中，System 属性是从Windows注册表中被初始化的，而在Linux/Unix中是由环境变量来进行初始化。initProperties方法的Javadoc声明，某些属性"必须保证被定义" 且列出它们。被java.util.TimeZone类的getDefault方法使用的三个System属性中，只有java.home作为一种“保证的”属性在Javadoc中被列出。 

推荐的解决方案 
     因此，你如何确保JAVA能给你正确的时间和日期呢？最好的办法是确认JAVA虚拟机（JVM）的默认TimeZone类是正确的，且是适合你的地理范围（Locale）的。你如何来确保默认TimeZone是正确的且适合的呢？这又是一个新问题了。象大多数处理的问题一样，这个也有许多解决方案。根据java.util.TimeZone.getDefault方法的源代码来看，最好的办法是正确地设置user.timezone属性。在启动JAVA虚拟机时,你能很容易的通过使用 -D 命令 -line 参数的办法来覆盖（override）在java.lang.System.initProperties方法中所设置的值。例如： 

java -Duser.timezone=Asia/Shanghai DateTest

这个命令启动DateTest类，并设置 user.timezone属性到Asia/Shanghai。你也能够通过使用java.lang.System 类的setProperty方法来设置user.timezone 属性:

System.setProperty("user.timezone","Asia/Shanghai");

 

如果没有一个可用的时间区域ID适合你，那么就你可以创建一个自定义TimeZone 使用java.util.TimeZone 类的 setDefault 方法将它设置为默认的时间区域----就象我先前在ItsInitializer 类中所做的操作一样。 

记住，在J2SE中，大多数日期和时间相关的类都包含时间区域信息，包括那些格式类，如java.text.DateFormat, 因此它们都会被JVM的默认时间区域所影响。然而，在你创建这些类的实例时，你能为它们确保正确的时间区域信息，使得你可以更容易来设置整个JVM的默认时间区域。并且一旦设置好，就可以确保所有的这些类都将使用同一个默认的时间区域。 

 

 

看到最后你是否发现，中国时间都信不过了，悲催哇，洗洗看电影睡吧！CCTV的报时也不一定是准的哇，靠人不如靠自己， 于是 就产生了 我靠！