C#中的DateTime在邏輯上有個很是嚴重的缺陷：html
> var d = DateTime.Now; > var d2 = d.ToUniversalTime(); > d == d2 false > d.Equals(d2); false
在C#交互模式中輸入以上代碼，能夠發現儘管一個是本地時間（d），一個是UTC時間(d2)，只是時區不同，但在這個世界上，應該屬於同一個時刻。然而兩個時間卻不相等。。。mongodb
緣由在於DateTime不存儲時區，或者說，只存儲了一個模糊的關於時區的字段Kind，它是DateTimeKind枚舉類型的，有三種取值：Utc/Local/Unspecified，當取值爲Unspecified時，則會有歧義。服務器
但我仍是要吐槽，若是d.Kind或d2.Kind中任意一個是Unspecified，那麼d != d2我能夠理解。可是上面的d.Kind是Local，d2.Kind是Utc，若是按照DateTime不存儲時區的邏輯，那麼這兩個統一轉換Utc或者Local時，那麼它們應該相等，事實上也是如此：網絡
> d == d2.ToLocalTime() true
若是把d的本地時間t1當作9，本地時間所處時區z1當作+8，相應的UTC時間t0當作1，UTC時間所處時區z0當作0，對它們作規範化處理：函數
那麼 d = t1-z1 = 9 - 8 = 1, d2 = t0 - z0 = 1 - 0 = 1 。post
然而 d != d2。這纔是它怪異的地方。this
以東八區爲例，在C#交互模式中輸入如下代碼：spa
> var d3 = new DateTime(2018, 1, 1); > d3 [2018/1/1 0:00:00] > d3.ToLocalTime() [2018/1/1 8:00:00] > d3.ToUniversalTime() [2017/12/31 16:00:00]
能夠發現，一個簡單的構造函數，開發者心中默認通常都是本地時間，然而它卻容許直接建立出一個既非本地時間、也非UTC時間的怪物。code
當d3轉成本地時間時，會把d3做爲UTC時間來加8小時。htm
當d3轉成UTC時間時，卻會把d3做爲本地時間來減8小時。
那麼d3究竟是本地時間仍是UTC時間呢？沒人清楚，除非它存在於一個很是小的局部做用域中，而且生命週期極短，這時候咱們也許能夠假設它爲本地時間。
然而這個本地時間也依賴於它的運行環境，若是是有幾臺時區不一致的計算機，閹割了時區信息的DateTime轉成字符串在網絡中傳輸到另外一個時區（好比隔壁的十一區）的另外一臺服務器中，解析出來後，所謂的東八區本地時間8點，到了日本，變成了既非本地時間、也非UTC時間的怪物。
DateTime在官方文檔中已經不推薦使用，而是推薦使用它的代替品DateTimeOffset，後者保存時區信息。
在交互模式中驗證一下：
> var dto = DateTimeOffset.Now; > var dto2 = dto.ToUniversalTime(); > dto == dto2 true
能夠發現，DateTimeoffset判斷兩個時間是否等價的標準，是以世界時間軸的時刻來判斷的，與時區無關，甚至能夠與UTC時間無關。只要它們都在同一個時間體系裏、能互相變換便可。
在實際項目中，建議你們：
- 若是有使用DateTime的，統一換成DateTimeOffset。
- 若是有用到32比特的UNIX時間戳的，統一換成64比特的long來存儲UtcTicks。
即便項目自己不跨時區，仍然有可能遇到時區問題，好比若是使用了mongodb的，mongodb存儲的時候都是統一存成UTC時間的（好像是，忘了）,並且通常來講會帶有時區信息。可是有一種狀況比較糟糕，若是你的DateTime的Kind是Unspecified的，隱含的時區的信息就會丟失。再取出來以後，就會有8小時的時差。有一些第三方的或者本身公司的類庫之類的，若是沒有處理好這個問題，也有潛在的時區丟失問題。UNIX時間戳存成Utc Ticks也有好處，不管是精度仍是時間跨度，都遠超UNIX時間戳。只須要64比特，便可得到下至100納秒的精度，上超萬年的時間跨度，一勞永逸，不管是轉回UNIX時間戳仍是JS時間戳，都能勝任。空間代價也很是小，除非你的存儲空間真的是硬傷。。