项目：.Net CS结构，WCF通信，MySql存储。

　场景：客户端（UTC+07:00）获取本地时间(DateTime对象)2017-01-17 15:20:12，通过WCF（http）传输至服务端,服务端(UTC+08:00)DateTime对象值变成2017-01-17 16:20:12，由于业务严重依赖字面值（年月日时分秒），所以。。。严重bug。

　查询一番发现，是时区相关概念在作怪，以前也没这方面认知，继续查MSDN资料，DateTime是包含了时区相关的信息，只不过有且只有他的Kind属性包含了时区有关的信息，并且是一个枚举：Unspecified，Utc，Local。当通过DateTime.Now获取到的DateTime对象，Kind值即为Local，而我的代码中获取客户端本地时间全部是DateTime.Now这一句。

　在.Net解决方案中，当Datetime对象跨时区时（Datetime对象-序列化-反序列化-DateTime）他会根据对象的Kind属性进行不同的处理

　　当Kind为Local：会进行时区换算，始终将对象值转换为本时区对应的值

　　当Kind为UTC：不会进行相应转换

　　当Kind为Unspecified：默认当做UTC方式处理，在某些场景也有区别于UTC

　所以，如果你期望DateTime对象的值在跨时区场景中始终保持不变，使用UTC是最好的选择，可以通过DateTime.SpecifyKind方法去修改一个已创建的DateTime对象的Kind值，并且他的Ticks值不变（当从数据库加载DateTime值并已DateTime对象跨时区传输时可以用此方式，貌似应该还有其他方式，可以Google）

　　我就是用上诉方式解决我遇到的问题的。

　　其实.Net还提供了DateTimeOffset来处理时区、时间相关的问题，他包含的信息比DateTime丰富，关于他的具体使用，我还没去查看，以及生命夏令时、冬令时相关的东西都没鸟他，滚一边去，以后直接String弄他。

　　另带：.Net是在序列化和反序列化的时候进行的时区换算，如果是以XmlSerialize来序列化，观察序列化的xml文件就会发现

　　　　　DateTime.Local会序列化为：2017-01-17T15:20:12.1522145+07:00

　　　　　DateTime.UTC会序列化为：2017-01-17T15:20:12.1522145Z

　　以上俩字符串可以通过DateTimeOffset.Parse()方式直接转成DateTimeOffset对象，此对象包含了原始时间和时区等信息，其实当时修复我遇到的问题的第一个想法是在服务端修改，也就是在服务端反序列化之前，将他的值偷偷换了，如此就完成解决（不用发客户端），但直到最好都不知道如何介入WCF那一块，所以最终还是发布了客户端。

　　　　具体参见：https://msdn.microsoft.com/zh-cn/library/az4se3k1(v=vs.100).aspx（标准日期和时间格式字符串）

　　同时提醒一下，MySql的DateTime对象会回毫秒作四舍五入。。。。

　　记录以上，以待以后查阅。