我正在浏览Scott Hanselman的"开发人员面试"问题列表，并遇到了以下问题：

What is wrong with
  DateTime.Parse(myString)?

虽然我知道解析未知格式或者原产地字符串存在固有的风险，但是还有其他原因吗？改用DateTime.ParseExact吗？首先应该是myString.ToString()吗？

解决方案

除了语言环境问题之外，DateTime.Parse()还可能引发异常，然后我们必须捕获该异常。请改用DateTime.TryParse()或者DateTime.TryParseExact()。

这篇博客文章对此进行了解释，但是一般的事情是没有与解析相关联的cultureinfo。

在系统上使用当前的线程区域性通常是一个坏主意，就像"尝试各种格式并查看它们中的任何一种是否起作用一样"。

具有特定文化的ParseExact是一种更加受控和精确的方法。 (即使我们指定了当前的区域性，也使读​​者对它的了解更加明显。)

正如MSDN所说：

Because the Parse(String) method tries
  to parse the string representation of
  a date and time using the formatting
  rules of the current culture, trying
  to parse a particular string across
  different cultures can either fail or
  return different results. If a
  specific date and time format will be
  parsed across different locales, use
  the DateTime.Parse(String,
  IFormatProvider) method or one of the
  overloads of the ParseExact method and
  provide a format specifier.

除了未知的用户输入，环境可能是未知的..因此，我猜想，即使我们控制输入格式，解析期望的结果也会有所不同。

这个问题只是看开发人员是否知道与此有关的问题。首先，我们应该使用TryParse，因为如果Parse无法解析，则Parse会引发异常。另外，它也没有考虑语言环境，因此在Web场景中，如果英国用户键入02/10/2008，并且我的服务器使用的是美国语言环境，那么我将获得2008年2月10日而不是2008年10月2日的信息。

可能还有其他问题，但是想到的是前两个问题。

我的直觉反应是，我们使用未知的格式/来源打了它。可能还有其他原因-例如，从那一行开始，我们是否知道myString是字符串？ (当然，我假设是的。)

通常，我建议改用TryParse方法。它稍微冗长一些，但是有助于防止异常-只要在无效输入的情况下代码能够正常运行即可。

当然，根据我们对此的表述……我想我们已经知道了这一切。 :)