32位的Windows系统，系统时间超过2106年2月7日6时28分15秒，系统会不会当场死机?

这个问题是2038问题的一个变体。

time_t这个类型其实是出自unix系统的，而不是C语言，但是早期C语言和Unix紧密捆绑，用到time_t的场合非常多，慢慢的它也就被认为是C语言标准库的一部分了，Windows等其他操作系统上的C语言编译器也采纳了Unix对time_t的规定。旧的32位的C语言库的time_t其实是32位int，0值对应的是1970年1月1日0时，到2038年1月19日，它就要溢出了。解决2038问题的最直接思路是把time_t改成64位，但是这会导致新旧代码的冲突，比如已编译好的静态库或者动态库存在的旧代码里面，已经把32位的time_t放在一个struct内部了，新程序要调用这个库，就不能使用64位的time_t。

目前主流C/C++语言的做法都是强制改为64位time_t（即使运行在32位系统上的32位编译器也要改），不兼容的应用程序自己去更新版本。但是也有一些程序为了继续使用旧的库，采用了投机取巧的办法，把time_t重新定义为32位的unsigned int，这样对现有程序的内存分布就没有影响了，而溢出的时间点被推迟到了2106年2月7日。

微软编译器并没有采用把time_t重新定义为unsigned int的做法，并且Windows内部根本不依靠time_t记录时间，Windows内部的时间是一个64位值，单位是100ns，起点是1601 年 1 月 1 日0点，这个数值到公元30828年才会溢出。所以绝大部分Windows核心和自带应用程序不会受到time_t溢出的影响，更不会系统崩溃。并且，从VS2005开始，微软的C运行库就使用64位的time_t，目前还在使用的应用程序遇到2038或者2106问题的概率微乎其微。