背景知识

闰秒是在在UTC（中文“世界标准时间”或“世界协调时间”／英文“Coordinated Universal Time”／法文“Temps Universel Cordonné”）是基于Atomic Clock（原子时钟）的一种时间，向太阳时（Solar Time ）对齐的一种方法，因为太阳时是根据地球公转来计算的。所以，1972年制定的UTC为了确保其时间相对于UTC的时间误差不能超过0.9秒，因此在过一段时间后需要加一秒。下图是有UTC以来闰秒的调整表（来自Wikipedia闰秒的中文词条）

从上表中我们可以看到，从1972年到现在，在这四十年里已经进行过25次的闰秒调整。闰秒是在每年6月或12月的最后一天的最后一分钟进行跳秒或不跳秒。是否加入闰秒由位于巴黎的国际地球自转和参考坐标系统服务（IERS – International Earth Rotation and Reference Systems Service）决定。如果决定加入闰秒，那么这一秒是被加在第二天的00:00:00前的，也就是说，时间会出现23:59:60的情况，然后才是第二天的00:00:00。如果是负闰秒的话，23:59:58的下一秒就直接跳到第二天的00:00:00了。现在，所有闰秒都是正闰秒。

计算机处理闰秒

那么，对于我们的电脑系统来说，怎么处理这个闰秒呢？一般来说，我们需要为我们的电脑系统配置UTC时钟，并通过NTP (Network time protocol)来进行时间同步，NTP服务器会一级一级地下发闰秒事件通知直到最边缘的NTP服务器，然后NTP服务器就会把闰秒通知发给客户端的操作系统，由操作系统来处理闰秒通知。

虽然闰秒调整对普通民众的日常生活不会产生影响。不过，这个问题将影响部分开启ntp服务的Linux操作系统——会导致Linux内核Crash！Linux kernel是在2.6.18-164.e15之后的版本中解决了这个问题。换句话说，Linux kernel低于2.6.18-164的Linux系统，无论是什么公司的Linux都将受到影响。（今晚过后大家可以查看一下你的Linux系统日志，看看闰秒有没有发生）

可以参看下面的bug描述：

• LKML: Chris Adams: Re: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009
• Bug 479765 – Leap second message can hang the kernel

那么，我们的操作系统是怎么处理正闰秒通知的？通常来说有三种实现：

1. 后退一秒。
2. 停止一秒。
3. 真正的增加一秒。

懂编程的人一眼就能看出来，前两种方式是以一种Workaround或Hack的方式解决这个问题。第一种方式会导致一些基于timestamp的消息通知乱序了，而第二种会导致出现两个一模一样的timestamp。最后一种不会出现timestamp的问题。对了，你还记得以前那篇《你确信你了解时间吗？》的文章吗？

最后，说说Windows，Windows  Time Service不支持闰秒通知，所以，当闰秒发生的时候，你的Windows上的时间会比实际时间快一秒钟，这需要等下一次的时钟同步才会完成修正。你可以查看这篇文章：http://support.microsoft.com/kb/909614/en-us

（全文完）

我在其中高亮了几行，这个程序就是想比较一下“1927-12-31 23:54:07”  和  “1927-12-31 23:54:08” 差几秒，很明显，是差一秒。但是程序的输出却不是这样的。

import java.text.SimpleDateFormat;
import java.text.ParseException;
import java.util.Date;
import java.util.TimeZone;
class time{
    public static void main(String[] args) throws ParseException {
        SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        sf.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"));
        String str3 = "1927-12-31 23:54:07";
        String str4 = "1927-12-31 23:54:08";
        Date sDt3 = sf.parse(str3);
        Date sDt4 = sf.parse(str4);
        long ld3 = sDt3.getTime() /1000;
        long ld4 = sDt4.getTime() /1000;
        System.out.println(ld3);
        System.out.println(ld4);
        System.out.println(ld4-ld3);
    }
}

下面，让我们来看看程序的输出：（是的，差出353秒钟来）

-1325491905
-1325491552
353

Stackoverflow真的很强大，在大家要求发问者给出时区（中国上海）的15分钟内就解决了这个问题。相当的令人惊叹。原因是什么呢？大家需要围观一下这个网页。（为了怕被墙或是被和谐，我已习惯了抓屏保存，如果有人能开发一个软件能随看随抓，然后如果源被删了可以P2P的从已下载了的人那里获取，那么这个软件应该会很有国内市场。蛋扯远了，Sorry）

从上图中我们可以看到—— 在1927年12月31日23:59:59时，往后面的一秒应该是1928年1月1日 0:0:0，但是这个时间被往后调整了5分52秒，而成了，1927年12月31日的，23:54:08，于是，完成了352秒的穿越。于是我们的Java程序出了这样的一个问题，这真是一个奇迹。

为什么会有这个调整呢？我居然Google不到，不过，我在这个timeanddate.com上查看了一下北京的时间，发现北京的时间只到1970年，于是我猜想，中国近代历史乱七八糟的政权交替可能是这个原因。于是我看 了一下北京和上海物理时差，果然，北京上海的时差在5分50秒左右。因此，我觉得这个时间的变化应该是从上海（南京）时间变成了北京时间。至于你信不信，反正我是信了。

从这个事，我得到下面的一些启示：

1. Java在的时区实现相当的强大啊。这种细节都能考虑到。
2. 本地时间的完全就是一锅粥，应该尽量不用。
3. 如果你要开发和时区有关系的程序，你的系统里一定要使用GMT标准时间，仅在显示的时候才转成本地时间。

在下周五或周六的某一时间，计算机的时间戳（TimeStamp）为变成奇妙的1234567890，而这一天就是——格林威治时间：2009年2月13日 11:31:30 。

当然，因为这个时间在地球上某些地方是13日，某些地方是14日，不同的时区可能会不一样。不过，你可以使用Unix/Linux 下的Perl运行一下这个命令你就知道你的当地时间了。

perl -e ‘print scalar localtime(1234567890),”\\n”;’

对于中国GMT+8（东八区）的时间如下：2009年2月14日 早上7点31分30秒，你会在这一时刻干什么？你会在某个地方做点什么事庆祝一下吗？或是你会因为今天是情人节而在这个时间给你的爱人发个短信吗？呵呵。

不过，西方某些迷信的还懂编程的朋友们开始显得有点焦虑，因为那天就是传说中的“黑色星期五”（13日星期五）。嘿嘿。

接下来是“科普教育”，名词解释

1）时间戳：从1970年1月1日 00:00:00 以来的秒数。

2）Y2K38：因为在Unix下，time_t 被定义成signed int，所以，有符号的32位整型本身有限(2147483647)，某一天这个整型为高位为一（负数），而这一个时间是——格林威治时间2038年1月19日03:14:07 。