mysql里奇怪的日期2016-2-7 14:28:15

    前两天数据库那边说数据库里出现了个奇怪的日期2016-2-7 14:28:15，当时我做一个和时间关联的功能的时候这个数就出现过。当时我也没太注意，以为自己做这个功能的时候可能那个时间值没有初始化，导致程序版本里出现一个随机的数，转换为时间就变这个了。现在版本都交了，程序都放外网上了，还有这问题，很明显不是我想的那么简单。这里说一下我的开发环境，winxp + visual stidio8，数据库是mysql。按理说，debug版本的时候值未初始化是给一个随机数。release版本的话未初始化的值都默认为0，不会出现这个问题。

    没办法只能顺藤摸瓜一个一个步骤排查，我做的功能是玩家登陆的时候从数据库里加载到玩家的所有信息，其中一项就是这个时间。然后通过这个时间和本地时间去对比，如果时间过了一个周，则用户可以领取上周的奖励。并且把这个时间跟新成当前时间，当用户下线的时候再保存的数据库里。如果没过一周的话，那存的就是从数据库里加载的数。由于比较时间和存储时间都转化为utc时间，就是从1970年1月一日零点零分零秒算起，到目前的秒数。传输的时候用的秒数。存储的时候转换为正常的时间格式 （方便查看）。那这个过程中到底是谁把时间污染了。一般情况下数据库负责存储时间，问题应给是我服务器问题。找了所有涉及到改变这个时间没有发现可疑的地方。这下可把大家难住了。

    这时大家讨论这个时间怎么来了，意思就是由哪个数转换而来的。可是一想不对啊，time_t是用int表示的从1970到目前的秒数啊。那int最大数是0X7fff ffff，转换成时间也就到2038啊。2016比这个时间大多了，那这个2016转换成秒数是多少呢，得出结果是0xffff ffff。也就是unsigned int最大数。那思路基本就理清了，传输time_t是转换为unsinged int传输的。那只能说time_t转换的时候传的值有问题。还有一个比较奇怪的问题，int的最大数比unsigned int最大正数小了一半，这个又是为什么呢。突然想起来，如果int是-1呢，装换为unsigned int不正好就是0xffff ffff吗？我服务器这边定义的关于时间类型都是unsiged int，那很明显了，这个值就是数据库传给我的。告诉了下数据库那边，数据库很无辜，说他只负责存储，和读取啊。

    好吧，那数据库初始化那个值是多少？0啊，听起来没错，可是琢磨一下有问题啊。数据库存储的是转换过的时间，就是正常的日期。正常的日期起始时间是1970啊，怎么能是0呢。问题终于发现了，也就很轻松解决了。但我比较疑惑的是mysql的函数怎么写的，如何将0年0月0日0时0分0秒转换为-1的。估计是mysql看到非法的时间直接返回-1了。这我猜测的，呵呵。等上班了，再去数据库那里看看mysql文档，是怎么个情况。

    总结一下，从这个问题的发现到解决。总共经历了：发现、猜测、验证、假设、反证这几个过程。这是解决一些列的问题的定式，同时大家在用数据类型的时候一定要清楚这个数据类型是如何定义的，范围是多少。免得发生灾难性的事件。要是银行就惨了，对吧。从-1转换为0xffffffff了。