我在瀏覽斯科特Hanselman的Developer Interview question list，以及跨越這個問題跑了：DateTime.Parse（myString）有什麼問題？
有什麼不對 DateTime.Parse（myString的）？
雖然我知道解析一串未知格式或來源的內在風險，還有其他原因嗎？它是使用DateTime.ParseExact來代替嗎？它應該是myString.ToString（）第一個？
此外，區域設置問題DateTime.Parse()也可能會引發異常，您將不得不趕上。改爲使用DateTime.TryParse()或DateTime.TryParseExact()。
TryParse/TryParseExact非常適合當數據來自一個不可靠的來源時，如果你有充分的理由相信無效數據代表了一個重大的系統錯誤，那麼拋出一個異常是正確的做法，把Parse轉換成TryParse並不是一個好主意。 – 2008-10-02 13:49:03
此博客文章explains it，但一般情況是沒有與解析相關的cultureinfo。
在系統上使用當前線程文化通常是一個糟糕的主意，因爲「嘗試各種格式，並查看它們是否有效。」
ParseExact與特定的文化是一個更加控制和精確的方法。 （即使你指定當前的文化，這使得它更明顯的讀者，這是發生了什麼事情。）
由於MSDN所說的那樣：
因爲解析（String）方法試圖 解析 的日期和時間使用格式 當前文化的規則，嘗試 跨 解析特定字符串的字符串表示形式不同的文化可能會失敗或 返回不同的結果。如果 特定日期和時間的格式將是 跨不同的區域解析，使用 的DateTime.Parse（字符串， 的IFormatProvider）方法或ParseExact方法的 重載之一和 提供一個格式說明。
除了未知的用戶輸入的環境可能是未知的......，所以我想，即使你控制輸入格式，有什麼期待解析可能會有所不同..
這個問題僅僅是看看開發者是否知道這個問題。首先，您應該使用TryParse，因爲如果Parse不可解析，則Parse會引發異常。此外，它不考慮區域設置，所以在網絡場景中，如果英國用戶輸入02/10/2008，並且我的服務器正在使用en-US語言環境，那麼我會在2008年2月10日之前取代2008年10月2日。
可能還有其他問題，但這些是前兩個想法。
我的直覺反應是你用未知的格式/原點擊中它。可能還有其他的原因 - 例如，從單行來看，我們知道那myString是一個字符串嗎？ （當然，我假設它是這樣的。）
通常我推薦使用TryParse方法。它稍微冗長些，但有助於防止異常 - 只要您的代碼在無效輸入的情況下適當運行。
當然，根據你的措詞這個......我假設你已經知道這一切。 :)
答案取決於圍繞DateTime.Parse（myString的），並解析
您可能已經檢查字符串是基於正則表達式是有效的格式要求的代碼，你可能不有趣的文化信息。您也可能知道數據來自已知日期約定的已知文件格式，因此拋出異常可能正是期望的。
沒有上下文的問題是相當模糊的，真正的答案，它必須是「這取決於其中的代碼被用作什麼是錯的情況下，如果
如果有人有興趣，我寫的關於這個問題在土耳其文的一篇文章[DateTime.Parse（string）kullanmayıbırakamazmıyız？]（http://sonergonul.net/datetime-parse-string-kullanmayi-birakamaz-miyiz/）。 – 2016-01-14 12:04:16