23

我在浏览 Scott Hanselman 的开发人员面试问题列表时，遇到了这个问题：

DateTime.Parse(myString) 有什么问题？

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

4

8 回答 8

28

除了语言环境问题之外，DateTime.Parse()还可能引发您必须捕获的异常。使用DateTime.TryParse()或DateTime.TryParseExact()代替。

于 2008-10-02T13:46:48.833 回答
14

在系统上使用当前的线程文化通常是一个坏主意，就像“尝试各种格式，看看它们是否有效”一样。

具有特定文化的 ParseExact 是一种更加可控和精确的方法。（即使你指定了当前的文化，它也会让读者更清楚这就是正在发生的事情。）

于 2008-10-02T13:47:19.940 回答
6

正如 MSDN 所说：

因为 Parse(String) 方法尝试使用当前区域性的格式规则解析日期和时间的字符串表示，尝试跨不同区域性解析特定字符串可能会失败或返回不同的结果。如果将跨不同语言环境解析特定的日期和时间格式，请使用 DateTime.Parse(String, IFormatProvider) 方法或 ParseExact 方法的重载之一并提供格式说明符。

于 2008-10-02T13:47:36.757 回答
3

这个问题只是看看开发人员是否知道这方面的问题。首先，您应该使用 TryParse，因为 Parse 会在不可解析时引发异常。此外，它没有考虑语言环境，因此在 Web 场景中，如果英国用户输入 02/10/2008，并且我的服务器使用的是 en-US 语言环境，我会得到 2008 年 2 月 10 日而不是 2008 年 10 月 2 日。

可能还有其他问题，但这是我脑海中浮现的前两个问题。

于 2008-10-02T13:49:39.513 回答
1

除了未知的用户输入，环境可能是未知的..，所以我猜即使你控制了输入格式，解析的期望可能会有所不同..

于 2008-10-02T13:48:22.153 回答
1

我的直觉反应是你用未知的格式/来源击中它。可能还有其他原因——例如，从那一行中，我们知道这myString是一个字符串吗？（我假设它是，当然。）

通常我推荐 TryParse 方法。它稍微冗长一些，但有助于防止异常——只要您的代码在输入无效的情况下表现得适当。

当然，根据你的措辞......我假设你已经知道了这一切。:)

于 2008-10-02T13:49:42.510 回答
0

这个博客文章解释了它，但一般情况是没有与解析相关的文化信息。

于 2008-10-02T13:47:00.613 回答
0

答案取决于围绕 DateTime.Parse(myString) 的代码和解析的要求

您可能已经检查了字符串是基于正则表达式的有效格式，并且您可能对文化信息不感兴趣。您可能还知道数据来自具有已知日期约定的已知文件格式，因此抛出异常可能正是我们想要的。

没有上下文，这个问题就很模棱两可，真正的答案必须是“它取决于使用代码的上下文，它有什么问题，如果

于 2011-11-01T10:52:54.443 回答