Format 1. Sun, 09 Oct 2016 13:24:35 GMT
Format 2. Sun, 9 Oct 2016 13:36:09 UTC

Format 1 是在IE裡面產生的（Windows10下的Edge和IE已經使用Format2）
Format 2 是Edge/Firefox/Safari/Chrome等產生的格式（這麼說不太嚴謹，應該帶上版本號）
那麼採用DateTime.TryParse，Format 1會報錯，而Format 2會成功。

我們先看一下C#下DateTime的格式，開啟TryParse的文件，很長，似乎看不懂。用ILSpy查一下原始碼，在程式碼中，我們似乎只能找到GMT字眼，卻找不到UTC字眼。

通過程式碼，我們知道了這樣的格式，C#DateTime中微軟遵循了RFC1123標準（從這裡扒出來的線索），我們找到RFC1123 第5.2.14節文件，5.2.14 Date and Time Specification章節，發現它引用的是RFC822 第5節的內容，在裡面關於zone的內容中，只提及了GMT作為關鍵字，並沒有使用UTC的字眼。

但是在IE中微軟toUTCString方法，僅提到了UTC時間，並沒有提到Format 1和Format 2之間的差異以及版本變更，在IE的版本變更資訊中也沒有提及具體的變化細節。

我們嘗試從其它瀏覽器的文件裡面找到蛛絲馬跡，於是來到了FireFox的官方文件

注意到在IE9和其它瀏覽器中都支援toISOString方法，這個方法，返回的正是以上格式的資料。
再回到toUTCString的各種定義，我們會發現一句話叫：生成人類可讀易讀的格式，比如C# DateTime的ToString可以傳遞格式o或者r，而且除了RFC1123中明確提到GMT字眼外，其它地方並未提到UTC，既然是給人閱讀的，人是聰明且智慧的，GMT還是UTC大家都能看懂，但是我們的命題其實是給機器讀的。這個時候，我們更建議使用ISO 8601的YYYY-MM-DDTHH:mm:ss.sssZ

臨時解決辦法：

既然IE舊版中的toUTCString方法，所產生的資料僅是UTC字眼和GMT字眼的差異，那麼在進行TryParse之前，替換一下字元即可。注意一點，在IE中，如果“日”為1位數的話，比如是10月9日，那麼可能顯示的是9 Oct，這個在ECMA的標準中，還是明確提到要補齊為“09”，不過對於C#的DateTime.TryParse，則沒有什麼影響。