所有使用POSIX时间表示时间的程序都将受2038年影响，因为它们的时间起点是格林尼治时间1970年1月1日0时0分0秒（这个时间名叫 the Unix Epoch），它们用the Unix Epoch经过的秒数（忽略闰秒）来表示时间。这种时间表示法在类Unix（Unix-like）操作系统上是一个标准，并会影响以其C编程语言开发给其他大部份操作系统使用的软件。在大部分的32位操作系统上，此“time_t”数据模式使用一个有符号32位整数(signed int32)存储计算的秒数。依照此“time_t”标准，在此格式能被表示的最后时间是第2147483647秒（代表格林尼治时间2038年1月19日凌晨03:14:07）。下一秒，即格林尼治时间2038年1月19日凌晨03:14:08，由于32位整型溢出，时间将会被“绕回”（wrap around）成一个负数，变成了第 -2147483648 秒（代表格林尼治时间1901年12月13日20:45:52），造成应用程序发生严重的时间错误，而无法运行。

解决方法有两个，要不换64位电脑和软件，要不在系统时间2038年1月1日之前把自动时间关掉再调到1990年，这样就能解决了

但是别人的脑洞没我那么大，他们认为目前并没有针对现有的CPU/操作系统搭配的简单解决方案。直接将POSIX时间更改为64位模式将会破坏对于软件、数据存储以及所有与二进制表示时间相关的部份的二进位兼容性。更改成无符号的32位运算器（integer）则会影响许多与时间改变相关的程序。大部份64位操作系统已经把time_t改为64位整型。不过，其他现有架构的改动仍在进行中，不过预期“应该可以在2038年前完成”。然而，直到2006年，仍然有数以亿计的32位操作系统在运行中，特别是许多嵌入式系统。相对于一般电脑科技18至24个月的革命性更新，嵌入式系统可能直至使用寿命终结都不会改变。

部分内容来自百度百科2038年问题，由于此吧太凉将转至bug吧

1、2038年1月19日凌晨03:14:分出问题我2038年1月19日凌晨03:13分回拨就可以了为啥要1月1日之前就开始忙活
2、只有受C语音编写的纯UNIX软件或系统软件才会受影响，你个人PC有时间同步机制而且又不是纯C有个屁的影响
3、最怕这种虫子的都是嵌入式等不可修改代码硬件了。只要能修改程序或者换个标准库就能解决