C#中的DateTime在邏輯上有個非常嚴重的缺陷： 在C#交互模式中輸入以上代碼，可以發現儘管一個是本地時間（d），一個是UTC時間(d2)，只是時區不一樣，但在這個世界上，應該屬於同一個時刻。然而兩個時間卻不相等。。。 原因在於DateTime不存儲時區，或者說，只存儲了一個模糊的關於時區的欄位 ...
C#中的DateTime在邏輯上有個非常嚴重的缺陷：
> var d = DateTime.Now; > var d2 = d.ToUniversalTime(); > d == d2 false > d.Equals(d2); false
在C#交互模式中輸入以上代碼，可以發現儘管一個是本地時間（d），一個是UTC時間(d2)，只是時區不一樣，但在這個世界上，應該屬於同一個時刻。然而兩個時間卻不相等。。。
原因在於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 。
然而 d != d2。這才是它怪異的地方。
以東八區為例，在C#交互模式中輸入以下代碼：
> 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時間的怪物。
當d3轉成本地時間時，會把d3作為UTC時間來加8小時。
當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時間戳，都能勝任。空間代價也非常小，除非你的存儲空間真的是硬傷。。
