DateTimeOffset在ToString()的神秘事件

最近早上08:xx多的時候，跑本機整測突然一個測試跑不過 。

下來Debug查說是比對值驗證 錯誤

測試情境是 datetimeoffset的value會存進資料庫，再查出來直接 做比對是否 正確

突然就這麼錯了覺得很怪，往下 追查，其比對的值出現了
2024/1/1 12:00:00 +00:00 vs 2024/1/1 00:00:00 +00:00

的情況，想說應該是24小時制的問題，因此寫了一小段程式驗證

        var valueHour12 = new DateTimeOffset(2024, 1, 1, 12, 0, 0, 0, offset: TimeSpan.FromHours(0));
        var displayToHour12 = new DateTimeOffset(2024, 1, 1, 0, 0, 0, 0, offset: TimeSpan.FromHours(0));
        
        var s = valueHour12.ToString("o");
        var sWithO = valueHour12.ToString();
        
        Console.WriteLine("valueHour12");
        Console.WriteLine(s);
        Console.WriteLine(sWithO);
        
        Console.WriteLine("displayToHour12");
        s = displayToHour12.ToString("o");
        sWithO = displayToHour12.ToString();
		
        object boxingHour12Am = displayToHour12;
        
        Console.WriteLine(displayToHour12.Hour);
        Console.WriteLine(s);
        Console.WriteLine(sWithO);
        Console.WriteLine(boxingHour12Am);
        //tostring 失真點
        var parsedDTOffset = DateTimeOffset.Parse(boxingHour12Am.ToString());
        Console.WriteLine(parsedDTOffset.Hour);
        
        //明確格式 不會失真
        parsedDTOffset = DateTimeOffset.ParseExact(displayToHour12.ToString("yyyy/MM/dd hh:mm:ss t z"), "yyyy/MM/dd hh:mm:ss t z", new CultureInfo("zh-TW"));
        Console.WriteLine(parsedDTOffset.Hour);

輸出結果如下，會發現指定12點的 跟指定0點的，在ToString()後，再解回Datetimeoffset的結果，hour會飄掉，具體來看是他現顯示成如下

試著把Console印出來結果如下

valueHour12
2024-01-01T12:00:00.0000000+00:00
2024/1/1 12:00:00 +00:00
displayToHour12
0
2024-01-01T00:00:00.0000000+00:00
2024/1/1 12:00:00 +00:00
2024/1/1 12:00:00 +00:00
12 //不明確格式解成了 12的數字
0 //明確格式可以正確解成0的Hour

這個知道為什麼後，解法很簡單，就是明確轉字串格式

不過 為什麼說神秘？

因為首先Windows的OS上不會有這個情況，ToString()至少會有PM, AM或上午, 下午，所以這個案例在Windows的PC上跑測試，目前看起來都 測不出來。目前是我是在Mac的Rider上測試，或許會有OS 的環境、語言差異，造成這個影響，不過我是從Rider上直接看到他的變數可視化 就是直接忽略了上午/下午，這個IDE上差異就比較特別，在Windows的Rider跟VS則都有上午/下午。IDE與OS之餘，可能也可以在Windows上安裝 Docker跑Linux看看，不過 若ToString()可以重現 0點變 成12的Hour屬性 ，就代表 非Windows系統就會有這種ToString()失真的情況！

第二個，只要過了 12點這個臨界點，例如台灣時間9點，代表 UTC凌晨1:00，再ToString()，就 不會有這個問題，可以解出 1的Hour，但是若是指定13點，就又會出現這個情況，一樣會解出1，分別會變成1點PM跟 13點，這樣的測試時間點若加上台灣時間的shifting(-8)，很容易混淆，或是誤以為沒問題，且若固定 時間，或隨機時間導致測試測不出來，而不知哪天會有重大的狀況。

設定為 13的情境如下:

例如我們都設定 是 測試資料為 早上10點，那這個問題不會炸，不然就是我們設定 固定 CICD整測 跑的時間都是早上11點，那可能抓到的時間也都沒問題

因此需要小心程式中任何 地方 datetimeoffset，tostring(), 序列化 或 檔案化 的部分會不會有失真的情節 ，將其格式明確統一地定好。

而今天 因為9:00前上班被抓到而探討一下這個問題也實屬運氣成份吧？