来源：IT168
“时间”不仅是中国古代诗歌的重要主题，在现代也颇受创作人的青睐。“盛年不重来，一日再难晨”，“时光一去永不回，往事只能回味”......这些朗朗上口的句子都告诉我们时间的河流只会向前奔涌，不会回头。但是，其实现代技术存在的一个bug，能让我们“时间倒流，回到过去。”
相信关注Linux的人应该都或多或少的听说过2038年问题，下面笔者就先介绍一下什么是2038问题。
如今，在手机和电脑上查看时间应该大多数人的习惯了吧。那你知道这些时间是怎么计算得来的吗?这就要追溯1970年，那时Unix被广泛用于商业和学术界，所以1970年就被定位Unix和类Unix系统的元纪。所有系统的时间设定都以1970年1月1日0点0分0秒为基准，当前系统时间=基准时间+秒数。
从实施到现在，设备的系统时间一直都能稳定运行没有出现差错，但是机智的科学家还是从中发现了问题。在当时16位字宽已经很大了，32位在当时的人们看来已经是接近无限大了，所以time_t(也就是上述公式中的秒数)定义为32为有符号整数类型。也就是说在32位系统上，time_t最大值为0x7ffffffff，之后会溢出变成负值，再明白的一点说也就是2038-01-19 03:14:07之后就会发生时间倒流，我们将重回1901年。
其实这种时间和存储之间产生的错误并不是第一次。为了节省空间，著名的女程序员Grace Hopper采用六位数来标记日期，随着COBOL语言的不断壮大，这种存储方式的弊端就显示出来了，后来居然发展成为了危害巨大的“千年虫”。
为了解决这个问题，政府成立专门委员会，在确保关键基础设施的情况下解决了这个问题。虽然从表面来看，2038与千年虫很相似，但解决起来却是更加棘手。
如果对用于存储时间值的time_t数据类型的定义进行更改，则应用程序中依赖于带符号32位time_t整数性质的一些代码会出现兼容性问题。假设time_t的类型更改为无符号的32位整数，那么治标不治本，这个问题仍会存在。
如果在64位架构的操作系统和程序中使用64位time_t整数，那么系统时间可以从现在一直持续到292亿年后。但是，如果粗暴进行，将会带来严重性的后果。你可以想象一下，也许那时所有的应用程序都要重新编写代码，也许那一天所有的服务都会下线，你存在银行和支付宝中的钱都可能会被清零......
对于Linux 2038导致的时光倒流你有哪些好的补救方法吗?如果2038年真的“时光倒流”，想象一下那时的你会在做哪些事情?
