Y2038,让我提前遇上了千年虫！

刚才浏览网易科技频道时读到了一篇文章http://tech.163.com/05/1231/10/269T38RK00091KUI.html让我想起了开发前几天的一个有趣的bug,我们称它为“警察抓小偷”。

开发组用的开发环境是VC6(不过我个人一直比较喜欢VC7.1),经过一段时间的紧张开发，我们准备提交一个用于开发测试的版本。不一会，就有Notes中收到了一大堆的bug单。其中一个问题就是在某一台机器上测试人员一点一个叫着“警察抓小偷”的目录，程序就会出错些莫名其妙的问题，而且是必然重现。经过仔细分析，问题定位到了CTime的构造函数。但我仔细看了一下MSDN，CTime的表示范围是“The upper date limit is 12/31/3000. The lower limit is 1/1/1970 12:00:00 AM GMT.”那为什么会出现问题呢？

最后，我打开VC6带的MFC的源代码看了一遍。唯一可能出问题的就在于mktime了。

_mktime32 returns the specified calendar time encoded as a value of type time_t. If timeptr references a date before midnight, January 1, 1970, or if the calendar time cannot be represented, _mktime32 returns –1 cast to type time_t. When using _mktime32 and if timeptr references a date after 03:14:07 January 19, 2038, Coordinated Universal Time (UTC), it will return –1 cast to type time_t.

_mktime64 will return –1 cast to type __time64_t if timeptr references a date after 23:59:59, December 31, 3000, UTC.

原来VC6的CTime内部用的是time_t就mktime,但也只有时间超过2038年1月19日03:04:17才会出这个问题呀，（看了MFC的源代码才觉得MSDN“有误”，因为我手上的MSDN是for VS2003的，可能CTime的表示范围是以VC7.1为准的吧）。我实现是想不明白，“现在才是2005年呀，怎么会有这种问题呀！2038,到那时我早退休了，就是出了Y2038，我也可以不管它。”。开发组的其它人员也一头雾水，甚至有人说“VC6就是bug多！”

最后，我实在是想不通，将测试人员的机器上那个目录下的所有文件都列了出来，看了半天，没看出什么。（或许是工作太长时间了，眼睛都花了。）突然眼睛一亮,“2098-1-1 00:00:00”。Oh,my god!

其实这并非测试人员事先设计好的用例。只不过是从网络上down的一个小的益智游戏而已。en,2098,益智游戏，真的让我益了一会智。“2098,警察抓小偷”，但成了我们在喝茶(某些成员也喜欢coffee)时的谈资了。

CTime=>COleDateTime,暂时解决了这个问题。Y2038,让我提前遇上了千年虫！