小心程序中的时间（时间调整/闰秒）

先来看一个java中关于时间计算的例子

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

public class Test {

	public static void main(String[] args) throws ParseException {
		String shanghaiTest1 = "1927-12-31 23:54:07";  
		String shanghaiTest2 = "1927-12-31 23:54:08";
		Test.testDate(shanghaiTest1, shanghaiTest2, TimeZone.getDefault());
	}
	
	public static void testDate(String date1, String date2, TimeZone timeZone) throws ParseException{
		TimeZone.setDefault(timeZone);
		SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
		Date d1 = simpleDateFormat.parse(date1);  
		Date d2 = simpleDateFormat.parse(date2);
		long ld1 = d1.getTime() /1000;  
		long ld2 = d2.getTime() /1000; 
		
		System.out.println(ld1);  
		System.out.println(ld2);  
		System.out.println(ld2-ld1);
		System.out.println(TimeZone.getDefault());
	}
}

输出：

 

-1325491905
-1325491552
353
sun.util.calendar.ZoneInfo[id="Asia/Shanghai",offset=28800000,dstSavings=0,useDaylight=false,transitions=19,lastRule=null]

 

上面的程序很简单

把1927-12-31 23:54:07和1927-12-31 23:54:08转换成秒，然后做差

正常人都会认为相差一秒，可是结果353却吓人一跳

 

有人在stackoverflow提出了这个问题，之后就有人给出了答案

在这里http://www.timeanddate.com我们可以看到原因，原来是标准时区被改变了。

 

http://www.timeanddate.com/ 写道

When local standard time was about to reach
Sunday, 1 January 1928, 00:00:00 clocks were turned backward 0:05:52 hours to
Saturday, 31 December 1927, 23:54:08 local standard time instead

 

其实不止是中国，下面再来一个莫斯科的例子

 

String moscowTest1 = "1916-07-03 00:00:48";  
String moscowTest2 = "1916-07-03 00:00:00";
Test.testDate(moscowTest1, moscowTest2, TimeZone.getTimeZone("Europe/Moscow"));

 

输出：

 

-1688265000
-1688265000
0
sun.util.calendar.ZoneInfo[id="Europe/Moscow",offset=14400000,dstSavings=0,useDaylight=false,transitions=78,lastRule=null]

http://www.timeanddate.com/ 写道

When local standard time was about to reach
Monday, 3 July 1916, 00:00:00 clocks were turned forward 0:00:48 hours to
Monday, 3 July 1916, 00:00:48 local standard time instead

 

http://www.timeanddate.com网站做的很有意思，当把鼠标放到左侧的钟表上时，会弹出一个窗口，演示时间是如何调整的。

 

我们经常这样计算：现在 + 24 * 60 * 60 * 1000 = 明天的这个时候，现在看来这个等式未必成立了。

 

最后我们看看闰秒的知识，下面内容来自维基百科

闰秒

 

闰秒是在协调世界时（UTC）中增加或减少一秒，使它与平太阳时贴近所做调整。UTC，是透过广播作为民用时的官方时间基础，它使用非常精确的原子钟来维护。要保持UTC与平太阳时的一致性，偶尔需要调整，也就是"跳个"1秒来做调整。在长时间的周期，必须添加闰秒不断的增加速度。闰秒的时间现在是由国际地球自转和参考座标系统服务（IERS）来确认，而在1988年1月1日之前是由国际时间局（BIH）承担这项职责。

当要增加正闰秒时，这一秒是增加在第二天的00:00:00之前，效果是延缓UTC第二天的开始。当天23:59:59的下一秒被记为23:59:60，然后才是第二天的00:00:00。如果是负闰秒的话，23:59:58的下一秒就是第二天的00:00:00了，但目前还没有负闰秒调整的需求。需要时的日长度必须低于1750-1892年的平均日长度，才会累积足够调整1秒所需要的时间。除了每天4毫秒的波动外，日长度自1700年以来都保持一样。然而，从历史上的日食观测则显示，自西元前700年以来，每个世纪的日长度大约增加1.7毫秒。

 

 

 

建议取消闰秒

 

全球定位系统服务界面委员会在得克萨斯州沃斯堡举行的第47届会议中宣布，他们已经邮寄出停止闰秒的表决案。这项表决的计划是：

1.2008年4月：国际电信联合会（ITU）的工作小组提出国际电信联合会的研究，推荐停止闰秒的7A计划案。

2.在2008年，研究小组通过邮件让各会员国投票表决该议案。

3.2011年10月：国际电信联合会无线电通讯组（ITU-R）释出他们的研究报告，Status of Coordinated Universal Time (UTC) study in ITU-R，为2012年1月在日内瓦举行的会议做准备；报告上指出，到目前为止，在2010和2011年回应此议案的联合国机构，在192会员国中有16个做了回复，13个赞成改变，3个反对，正反比是13:3。

4.2012年1月：国际电信联合会决定在2015年的世界无线电会议中再决定闰秒的存废。法国、意大利、日本、墨西哥和美国倾向支持，加拿大、中国、德国和英国倾向反对。其它，包括尼日利亚、俄罗斯、和土耳其则呼吁要再多研究。BBC国家国际电信联合会决定进一步研究对大众传播社群的影响。

5.2015年：世界无线电会议将对此问题作成决议。

 

 

闰秒的原因

 

需要闰秒的部分原因是因为平均太阳日的长度正以非常缓慢的速度增加中，另一个原因是原子钟赋予秒固定的时间长度。而当结合时，就已经比当时的太阳时的秒短少了一点点。时间现在是以稳定的原子钟来测量（TAI或国际原子时），而地球自转有着许多的变量。

 

以国际单位的秒为基准，从1962年至2010的每日长度改变。

最初，秒是依据地球绕着轴自转和绕太阳的公转，以平均太阳日的1⁄86400来定义（参见太阳时）。到了20世纪中叶，很明显的，地球自转没有提供足够一致的标准，于是在1956年改以绕太阳轨道公转一年的时间重新定义秒。在1967年，秒又被以物理学的属性再一次重新定义：以铯133的振荡频率来定义秒，并可以用原子钟来测量。但主要由于潮汐加速，太阳日变成每世纪增长1.7毫秒（每世纪2.3ms，但冰河反弹会缩减0.6ms）

 

 

闰秒对程序造成的影响

我们来看看最近一次（2012-06-30）调整闰秒对程序的影响,下面内容转自新闻网站

搜狐IT消息 写道

北京时间7月2日消息，据国外媒体报道，上周日晚Reddit、Mozilla和Gawker等多家网站遭遇短暂的技术故障，原因在于在将“闰秒”加入世界原子钟的过程中，支撑这些网站操作的软件受到影响。
上周六，格林威治时间午夜，从6月跨越到7月的过程中，地球官方时间将回拨一秒，以保持和地球每日自转同步。根据网上的多篇报道，包括Liunx操作系统和Java应用平台在内的多个软件基础平台无法处理这多出来的一秒。
许多计算机系统使用网络时间协议（NTP）来保持与世界原子钟的同步，当一秒被增加后，一些系统根本不知道如何处理。
就在“闰秒Bug”出现之前，互联网刚刚从亚马逊网络服务的当机中恢复过来。作为最成功的商业云平台，很多网站都放置在亚马逊的平台上，占到了互联网总数的约1%。包括谷歌在内的一些网站提前预见到了“闰秒”的问题并为此做好了准备，但其他很多网站对这件事就没有这么上心。
新闻聚合和讨论网站Reddit就遭遇“Java/Cassandra”问题。Java/Cassandra”是Facebook用Java开发的开源数据库。不过Reddit没有回应关于此事的置评要求。
与此同时，Mozilla网站稳定性工程师，同时又是火狐浏览器开发者的Eric Ziegenhorn发布了一份bug报告，称Mozilla正遭遇Hadoop问题。Hadoop是另一个用Java开发的开源平台。自从午夜出现问题之后，Ziegenhorn 同样将这一问题归咎于闰秒。
其他人则抱怨Linux服务器出现问题。根据BuzzFeed的报道，Foursquare、Yelp、LinkedIn、Gawker和StumbleUpon同样受到闰秒bug的困扰。这5家网站中只有Gawker回应了置评要求，声称它因为使用了Tomcat网络服务器架设自己的网站而遭遇“闰秒”问题。
上周五Foursquare承认网站因为亚马逊的云服务关闭而当机。但它并没有承认因“闰秒”引发的错误。
Opera软件资深系统管理员，Opera浏览器开发者Marco Marongiu曾就“闰秒”问题发出警告，并提供多种可能的变通方法。但正如他指出的，“闰秒”问题并不新鲜。自从上世界70年代初设立原子钟以来，已经出现了约25次闰秒。
去年9月，谷歌在一篇帖子中详细阐述了如何处理闰秒问题。这家网络巨头使用了一种叫做“闰秒弥补”的技术，也就是在官方闰秒到来之前，逐步在自己的系统时钟中增加毫秒。
谷歌表示，这意味着当时间在午夜新增一秒，公司的时钟已经考虑到了这一点，并通过偏移时间的方法来解决。公司所有服务器可以继续正常提供服务，而根本不用顾及“闰秒”问题。

 

 

转贴请保留以下链接

本人blog地址

http://su1216.iteye.com/

http://blog.csdn.net/su1216/