4

我正在尝试使用DateTime.ParseExact. 它可以在任何地方工作,除了在一台机器上 - 它只是不会在那台机器上解析。问题是:为什么?那台机器上可能有什么不同,以至于它会导致这种行为?

以下是我已经看过的一些内容:

  • CultureInfo传递给DateTime.ParseExact,即CultureInfo.InvariantCulture
  • 流氓机器上的区域设置与解析工作的机器上的设置相同。
  • 是的,字符串格式正确,即dd/MM/yyyy HH:mm:ss
4

4 回答 4

6

我总是发现区域设置可能很棘手,而且您永远不能假设您的应用程序的用户甚至会首先正确设置他们的机器!

如果日期必须是字符串,我一直在用它来解析日期的全部内容是以“dd/MMM/yyyy”格式解析它,例如“14/JAN/2009”无论如何都会很好地翻译设置是。

顺便说一句,这个技巧也适用于 SQL Server :)

于 2009-01-14T03:10:22.150 回答
1

如果没有异常信息(Marc Gravell 询问)和/或一些示例代码,很难猜测解决方案可能是什么。

根据我的经验,由于文化问题,我在日期/时间方面遇到了问题。你说过你已经尝试过硬编码。

流程在其中运行的实际文化如何?如果此代码位于 asp.net 网站中,则根据用户浏览器设置(在请求中传递)设置文化。

尝试在您的代码中执行此操作以对当前线程文化进行硬编码,以查看这是否有助于进一步调试此问题。

// Replace the culture with whatever you required.
System.Threading.Thread.CurrentThread.CurrentCulture = 
    CultureInfo.CreateSpecificCulture("en-GB"); 

告诉我们当你尝试时会发生什么?** 当我们没有足够的信息时,我讨厌输入答案。这更像是一个建议而不是一个答案:)

于 2009-01-14T00:45:34.253 回答
0

确保不工作的机器上的区域设置与工作的机器相匹配。为避免将来出现此类问题,请在解析时指定文化。

于 2009-01-14T01:13:59.780 回答
0

我同意 Pure.Krome 需要更多信息。为此,问题:

  • 抛出了什么异常?
  • 您正在调用哪个方法重载,以及您传递给它的具体内容是什么?
  • 您是否验证过所有机器上的 .NET 运行时版本都相同?包括服务包版本?
  • 您正在解析的字符串是由您的程序生成的还是来自外部来源?如果它是外部的,您是否验证过该字符串在流氓盒子上没有以某种方式不恰当地转义?可能创建字符串的任何程序的版本都已过时并且其中存在错误。
于 2009-01-14T01:49:48.007 回答