unix时间2038问题

自从找到工作之后好久没有更博客了。。。今天写php的时候遇到了个神奇的问题，现在来说一说~

在php的时间方法里，mktime用的是unix时间戳，返回一个日期的 UNIX 时间戳。然后使用它来查找该日期的天。
语法：

mktime(hour,minute,second,month,day,year,is_dst);

如图，当我将year设为2038时

效果如下，可正常显示为2038年1月1日

but~当我将year改为2050年时————

什么鬼？！我明明写的2050年好吗？！为毛给我显示成1970年1月1日？？
于是不信邪的我又尝试了其他的时间，发现只要year大于2038就显示成1970！！what？这么神奇？！难道2038年是世界末日嘛！！

在一番脑洞大开之后，我仔细观察了一下，1970-1-1 08:00:00 咦？怎么这个时间这么熟悉呢？？这不是UNIX时间戳为0的时间嘛。。。

于是我去网上查了一下关于unix时间戳相关的知识，发现：

所有使用UNIX时间表示时间的程序都将受其影响，因为它们以自1970年1月1日经过的秒数（忽略闰秒）来表示时间。

依照此“time_t”标准，在此格式能被表示的最后时间是2038年1月19日 03:14:07，星期二（UTC）。超过此一瞬间，时间将会被掩盖（wrap around）且在内部被表示为一个负数，并造成程序无法工作，因为它们无法将此时间识别为2038年，而可能会依个别实作而跳回1970年或1901 年。错误的计算及动作可能因此产生。

其实就是在32位系统上，长度溢出导致的异常。

嗷嗷原来是这样啊。。那2038年之后咋办呢？这不马上就要到了么？毕竟我还年轻⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄

于是，找到了这个 ↓

开源自由软件社区开始对2038年问题展开努力

好吧好吧(∩_∩)，这我就放心啦~

所以叻~遇到2038这个问题的同学们就不用担心啦，安心用吧，会有替代方案的，我们就坐等问题解决吧O(∩_∩)O~~