【Java】有关System.currentTimeMillis()的思考

在Java中无须引入任何类利用System.currentTimeMillis()能够轻松地取出1970年1月1日到现在的毫秒数，利用它能够轻松产生时间戳，甚至import java.text.SimpleDateFormat; import java.util.Date;之后配合new SimpleDateFormat("yyyy年MM月dd日hh：mm：ss E").format(new Date(System.currentTimeMillis())).toString();能够清楚输出当前的系统的年月日时分秒星期几。比如：

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

public class JavaDate {
	public static void main(String[] args) {
		System.out.println(new SimpleDateFormat("yyyy年MM月dd日hh：mm：ss E").format(new Date(System.currentTimeMillis())).toString());
	}
}

运行结果就是当前系统的时间，如：2015年02月05日11：32：58 星期四

其中表示月的MM必须大写，区分表示分的mm

相信很多人都会了。

不仅是Java，很多编程语言都以1970年1月1日作为原点，这里面有个故事：1969年8月，贝尔实验室的程序员肯汤普逊利用妻儿离开一个月的机会，开始着手创造一个全新的革命性的操作系统，他使用B编译语言在老旧的PDP-7机器上开发出了Unix的一个版本。随后，汤普逊和同事丹尼斯里奇改进了B语言，开发出了C语言，重写了UNIX，新版于1971年发布。那时的计算机操作系统是32位，时间用32位有符号数表示，则可表示 68 年，用32位无符号数表示，可表示136年。他们认为以1970年为时间原点足够可以了。 因此，C的time函数就这么定了，后来的java等也用它，微机也用它，工作站本来就是unix系统当然也用它。由于主流计算机和操作系统都用它，其他仪器，手机等也就用它了。

然而System.currentTimeMillis()的返回值为Long，问题就来了，Long是有长度的，它只能代表一个长达32位的毫秒数，1970年1月1日逝去2G毫秒，也就是2147483647毫秒之后是2038年1月19日星期二晚上03:14:07。正如IP4的地址居然用尽一样，当时的科学家根本就没有想到计算机系统的普及率在今天觉得几乎人手几台一样，他们也没想到到了2038年1月19日星期二晚上03:14:07人们还会对智能系统进行研究，计算机居然不会淘汰，而是成为了必需品！

和本世纪初的千年虫（Y2K Bug）问题类似，计算机系统千年虫问题又称为2038年问题（Y2K38 BUG）。2038年问题不仅比千年虫更隐蔽，而且比之前千年虫问题更具有破坏力，因为千年虫问题只会导致应用层的程序出现问题，比如信用卡支付系统，或者管理系统。而2038这个bug，将会影响系统最底层的时间控制的功能。当时千年虫问题，已经困扰了很多部门了，不过最后把所有用00表示的时间，改成四位数字就可以了，但是2038年问题，必须改变内部表示时间控制的长度问题，可是现在推广64系统困难，中国大部分系统还是在WinXp的现状，先别说用户了，你让程序猿写出来的软件能够不兼容IE6，WINXP再说……更不要说64位机器了，很多电脑现在还不过是Win7 32位罢了！