昨天Tester发现数据有问题，大部分时间“datetime类型”都多了一秒，很少一部分数据的时间能完全对上（年月日时分秒），因为缺少关键日志，就各种排查，最后发现在调用Savechange方法前一刻数据都是对的，然后去数据库查询，数据就对不上了：时间多了一秒
骂娘之后，开始分析存储的Datetime对象（抽取了两个代表）
数据1：
{1/3/2017 5:50:04 PM}
Date: {1/3/2017 12:00:00 AM}
dateData: 9859562662895793936
Day: 3
DayOfWeek: Tuesday
DayOfYear: 3
Hour: 17
InternalKind: 9223372036854775808
InternalTicks: 636190626041018128
Kind: Local
Millisecond: 101
Minute: 50
Month: 1
Second: 4
Ticks: 636190626041018128
TimeOfDay: {17:50:04.1018128}
Year: 2017
数据2：
{1/3/2017 5:52:35 PM}
Date: {1/3/2017 12:00:00 AM}
dateData: 9859562664412782254
Day: 3
DayOfWeek: Tuesday
DayOfYear: 3
Hour: 17
InternalKind: 9223372036854775808
InternalTicks: 636190627558006446
Kind: Local
Millisecond: 800
Minute: 52
Month: 1
Second: 35
Ticks: 636190627558006446
TimeOfDay: {17:52:35.8006446}
Year: 2017
看了部分数据之后，第一反应就是四舍五入了（红色部分）
继续验证猜测：将Datetime对象的毫秒置0
再次大量数据测试，完全正确，问题算是解决了。
至于在哪个环节对数据进行了四舍五入，Google一下，未发现目标就没在继续纠结了。
同样，Firebird数据库未发现此问题（不知是否有相关设置之类，俺不纠结他了）