要是以前问我programming以来碰到的最困难的bug，我可能一下回答不出，但是今天碰到了一个bug，解决之后回想一下，发现最困难的就是这类的bug－与时间相关的数据问题。这类问题由于和数据计算的时间有联系，导致了这类问题发生的上下文往往无法重现，根本没有办法进行调试。

这次碰到的问题是企业生产系统中计算的外购数量发生错误。外购数量根据订单订购数量以及企业当时该种货物的库存计算得到的，也即与特定的时间点相关。生成的外购数量中部分正确，部分有问题，由于将所有数据恢复到当时情况进行重新计算与调试，很难有地方可以入手查找问题的根源（当然，这里也可能是因为我们的日志做的还不够好）。程序代码检查了没有发现问题，直接查数据库中的数据也没有办法得到答案，后来碰巧发现两张出错订单的制单日期均是在20日之前，于是猜想20日之前的那个版本中程序有问题，但是现在已经解决。但是这一猜想也无法证实，因为正确的版本的发布时间已经想不起来了。终于通过FTP上的文件（文件中包括了发布时间，15日和20日均发布了一个版本）以及JIRA中对于这一bug的记录（记录日期为15日，解决日期为17日），确定了正确的版本肯定是在17日之后发布的，也即20日发布，在20日之前的数据都存在问题，但是20日之后的数据均正确。

解决这一bug一共查找了系统源码，db数据，ftp发布文件，jira中bug记录等四处的信息才定位到问题原因所在。和做数学题一样，其实题目并没有超纲，只是多拐了几个弯的话做起来就很难了。而这里会需要多拐弯的原因正是在于时间信息无法重现，只能通过多个信息源共同来确定问题的可能原因。

基本上没有什么办法能够避免此类问题的发生，唯一的比较好的解决办法是在系统中进行完善的日志记录，保证能够捕获系统中大多数时间点上发生的事件情况，从而能够较好的重现bug发生时的现场使得bug能够快速定位。