Convert.ToDateTime 在下午的日期/时间值上导致 FormatException

Question

我们有一个应用程序解析以下格式的日期/时间值：

2009-10-10 09:19:12.124
2009-10-10 12:13:14.852
2009-10-10 13:00:00
2009-10-10 15:23:32.022

一台特定服务器突然（今天）开始无法解析 13:00:00 或之后的任何时间。该特定客户端有五台服务器，只有一台出现问题。我们还有数十个其他客户端，总共数百台服务器都没有出现问题。

System.FormatException: String was not recognized as a valid DateTime.
at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
at System.DateTime.Parse(String s, IFormatProvider provider)
at System.Convert.ToDateTime(String value, IFormatProvider provider)
at System.String.System.IConvertible.ToDateTime(IFormatProvider provider)
at System.Convert.ToDateTime(Object value)

我使用 DateTime.Parse(s, CultureInfo.CurrentCulture) 与 DateTime.Parse(s, CultureInfo.InvariantCulture) 进行比较，进行了测试，问题仅出现在 CurrentCulture 中。然而，CurrentCulture 是“en-US”，就像所有其他服务器一样，我在区域或语言设置中找不到任何不同之处。

有人见过这个吗？与我可以研究的内容相关的建议？

编辑：感谢您到目前为止的回答。但是，我正在寻找有关要研究哪些配置的建议，这些配置可能会导致其行为突然改变并在运行多年并在数百台其他服务器上运行时停止工作。我已经在下一个版本中更改了它，但我正在寻找配置更改来在当前安装的过渡期间修复此问题。

Answer 1

如果您确切地知道格式，请告诉应用程序它是什么 - 使用 DateTime.ParseExact 而不仅仅是 DateTime.Parse。 （正如其他人所说，还要指定不变的区域性，以消除更多的变化。）这给了你更多的控制权：

using System;
using System.Globalization;

class Test
{
    static void Main()
    {
        Parse("2009-10-10 09:19:12.124");
        Parse("2009-10-10 12:13:14.852");
        Parse("2009-10-10 13:00:00");
        Parse("2009-10-10 15:23:32.022");
    }

    static readonly string ShortFormat = "yyyy-MM-dd HH:mm:ss";
    static readonly string LongFormat = "yyyy-MM-dd HH:mm:ss.fff";

    static readonly string[] Formats = { ShortFormat, LongFormat };

    static void Parse(string text)
    {
        // Adjust styles as per requirements
        DateTime result = DateTime.ParseExact(text, Formats, 
                                              CultureInfo.InvariantCulture,
                                              DateTimeStyles.AssumeUniversal);
        Console.WriteLine(result);
    }
}

Answer 2

我们也遇到了同样的问题。只需回收您的应用程序池即可。

Answer 3

我们有一个在 Windows 2003 服务器上运行的 C# .NET 2.0 Web 服务。该服务已经运行了两年多。我们最近开始在该应用程序中遇到错误。错误消息是“字符串未被识别为有效的日期时间”。另一个网络服务返回一个日期，该函数应该返回一个类似的值

“2010 年 5 月 10 日 12:00:00 上午”

当发生错误时函数返回

“2010年5月10日12:00:00”

错误的返回末尾有空格且没有 AM。

在接下来的几周内，这个问题多次出现又消失。检查 Windows 日志后，我们注意到错误的开始和结束时间与设置（默认情况下）每 29 小时发生一次的应用程序池回收时间一致（在一两分钟内）。此问题仅出现在生产 Web 服务器上，而不会出现在开发或测试服务器上。我们尝试更换服务器，一个月没有出现任何错误。现在错误又开始了。我们手动重置池，问题立即消失。我们不希望将此视为可接受的解决方案，因为池会定期回收。我们不知道是否需要池回收，但我们的理解是定期回收有助于提高应用程序性能。

Web 应用程序已经使用 ParseExact()，但格式字符串如下所示：

“yyyy-MM-ddHH:mm:ss.0Z”

而不是

“yyyy-MM-dd HH:mm:ss”

Jon Skeet 在此线程中建议 。我不知道这是否会产生很大的影响。

我们还检查了文化设置。

很明显，问题始于应用程序池回收，但我不知道回收期间幕后发生了什么。大多数情况下，回收不会产生负面影响，并且当错误确实发生时，下一次回收总是会停止错误。

Answer 4

解决方案非常简单，使用CultureInfo.InvariantCulture。对于样本数据，这是唯一明智的做法。

我知道这并不能解释其中的差异，但你的软件确实不应该依赖于“默认”文化（也许在用户界面中除外）。

Answer 5

我刚刚找到了一些有关导致此问题的原因的信息。我们的 C# 客户端将业务日期（仅日期）作为字符串值发送到 Web 服务。 Web 服务将 SqlParameter 中的此字符串传递给 SqlCommand 以及接受业务日期的 datetime 参数的存储过程。

客户的系统突然出现异常。我使用 SQL Server Profiler 观察 RPC 调用，并注意到日期参数突然包含了时间部分。这应该是仅日期值 - 即 10/27/2012 12:00:00 AM。

我修改了存储过程以添加 WAITFOR DELAY '00:01:00'。然后，当 Web 服务调用该存储过程时，我获取了该 Web 服务的内存转储。

检查内存转储，我发现客户端在参数数据集中传入了正确的日期字符串“2012-10-25 00:00:00”。 Web 服务在调用存储过程时以某种方式搞乱了这些日期的转换。我在转储中找到了 SqlCommand，并检查了与存储过程的日期参数相对应的 SqlParameter。该值为“10/25/2012 12:00:00 PM”。

查看所有 CultureInfo 对象，我发现“en-US”的区域设置 1033 有一个很长的字符串“h:mm:ss tt”。 AMDesignator 是“AM”，但是PMDesignator 是一个空字符串！我通过运行以下命令验证了这是 C# 中错误日期的原因：

// clear the PM designator
System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.PMDesignator = ""
// this will yield "12/25/2012 12:00:00 " (note the extra space at the end)
Convert.ToDateTime("10/25/2012").ToString()

结果是“10/25/2012 12:00:00”，这与 Brian Begley 的答案相对应。使用不变格式会产生非常相似的结果：

// clear the PM designator
System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.PMDesignator = ""
// this will yield "10/25/2012 12:00:00"
Convert.ToDateTime("10/25/2012").ToString(System.Globalization.CultureInfo.InvariantCulture.DateTimeFormat)
// restore the PM designator to "PM"
System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.PMDesignator = "PM"
// this will yield "10/25/2012 00:00:00"
Convert.ToDateTime("10/25/2012").ToString(System.Globalization.CultureInfo.InvariantCulture.DateTimeFormat)

我尚未确定导致 CultureInfo 损坏的原因。

请注意，Microsoft 已意识到此问题。链接的文章说它仅适用于 Windows Server 2003，并且有一个可用的修补程序。

Answer 6

听起来好像文化对象不理解军事时间符号。老实说，我不确定从哪里开始，但它可能会给你一个起点。

Answer 7

CultureInfo.DateTimeFormat 属性的值是多少？ 根据 MSDN：

“用户可能会选择覆盖
一些与相关的值
当前的 Windows 文化
区域和语言选项部分
控制面板。例如，
用户可以选择显示日期
以不同的格式或使用
默认货币以外的货币
文化。

如果 UseUserOverride 为 true 并且
指定的文化与当前的文化相匹配
Windows 文化，CultureInfo
使用这些覆盖，包括用户
的属性设置
返回 DateTimeFormatInfo 实例
通过 DateTimeFormat 属性，以及
NumberFormatInfo 的属性
NumberFormat 返回的实例
财产。如果用户设置是
与文化不相容
与 CultureInfo 相关联，对于
例如，如果所选日历是
不是可选日历之一，
方法的结果和值
的属性未定义。

DateTimeFormat 的值
属性和 NumberFormat 属性
直到您的
应用程序访问该属性。如果
用户可以改变当前
文化转变为新文化，同时
应用程序正在运行，然后
应用程序访问
日期时间格式或数字格式
属性，应用程序检索
新文化的默认设置
而不是覆盖
原始文化。为了保存
覆盖原始电流
文化，应用程序应该访问
日期时间格式和数字格式
更改当前属性之前
文化。”

可能是某些用户设置覆盖了这一点？

Answer 8

这是一个疯狂的猜测，但也许像这样的事件序列可能导致了问题：

1. 管理员进入所有服务器上的控制面板国际设置并将时间格式从“HH:mm:ss”更改为“hh:mm:ss” tt”。
2. 管理员仅在其中一台服务器上回收应用程序池（或IIS服务，或机器）。

回收的服务器上的所有新 ASP.NET 工作线程现在都将看到更改后的时间格式，并且它们的 DateTime.Parse 方法将失败。但是，如果其他服务器仍在使用原始工作线程，则它们尚未检测到当前区域性 DateTimeFormatInfo 的更改。

这是一种非常不可能的情况，但话又说回来，你遇到了一种非常不可能的情况。您可以尝试回收所有服务器上的相关应用程序池，看看是否有任何变化。