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 = 8 - 8 = 0, d2 = t0 - z0 = 0 - 0 = 0 。

然而 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時間戳，都能勝任。空間代價也非常小，除非你的存儲空間真的是硬傷。。

C#中DateTime的缺陷與代替品DateTimeOffset