也说DateTime.ToString()，说datetime.tostring

也说DateTime.ToString()，说datetime.tostring

曾遇到过这样一个bug，测试描述说一旦设置了浏览器的语言为Portuguese/Brazil[pt-br]，对机器的reconfigure request就会fail。而当浏览器语言为en-us时，request则没有问题，如我们所愿的正常pass，贴图如下：

pt-br

en-us

起初接到这个bug时，百思不得其解！pt-br有什么特殊之处？何德何能？怎么到你这儿就敢对我们的request说个不字？……

 

查看log，发现这样的错误信息。

Exception oftype 'System.Web.HttpUnhandledException' was thrown. Inner Exception: Stringwas not recognized as a valid DateTime.

 

咦？既然是DateTime问题，那么其他语言，例如fi，de甚至zh也应该都有问题啊？不应该是pt-br特有的才对。立刻对我的想法进行验证吧，果不其然，切换浏览器语言为zh，de之后，reconfigure的request同样会导致失败。

 

继续走读代码，终于发现真凶原来隐匿在这里 this.RequestDate.DateUtc.ToString(); 

那要怎么破呢？其实只需修改ToString为ToString(s)即可。为了更好的说明该问题的成因，需要做一个简单的演示：

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-us");
DateTime dateValue = new DateTime(2016, 8, 24, 12, 34, 56);

Console.WriteLine("====================缺省格式====================");
Console.WriteLine(dateValue.ToString());

Console.WriteLine("====================标准格式====================");
string[] standards = {"d", "D", "f", "F", "g", "G", "m", "o", "R", "s", "t", "T", "u", "U", "y"};           
foreach (string standardFmt in standards)
{
    Console.WriteLine("{0} -> {1}", standardFmt, dateValue.ToString(standardFmt));
}

Console.WriteLine("====================自定义格式====================");
string[] customs = {"h:mm:ss.ff tt", "d MMM yyyy", "HH:mm:ss.f", "dd MMM HH:mm:ss", @"\Mon\t\h\: M", "HH:mm:ss.ffffzzz" };           
foreach (string customFmt in customs)
{
    Console.WriteLine("'{0}' -> {1}", customFmt, dateValue.ToString(customFmt));
}

 

当代码中的culture为pt-br时候，运行结果如下。

====================缺省格式====================
24/08/2016 12:34:56
====================标准格式====================
d -> 24/08/2016
D -> quarta-feira, 24 de agosto de 2016
f -> quarta-feira, 24 de agosto de 2016 12:34
F -> quarta-feira, 24 de agosto de 2016 12:34:56
g -> 24/08/2016 12:34
G -> 24/08/2016 12:34:56
m -> 24 de agosto
o -> 2016-08-24T12:34:56.0000000
R -> Wed, 24 Aug 2016 12:34:56 GMT
s -> 2016-08-24T12:34:56
t -> 12:34
T -> 12:34:56
u -> 2016-08-24 12:34:56Z
U -> quarta-feira, 24 de agosto de 2016 04:34:56
y -> agosto de 2016
====================自定义格式====================
'h:mm:ss.ff tt' -> 12:34:56.00
'd MMM yyyy' -> 24 ago 2016
'HH:mm:ss.f' -> 12:34:56.0
'dd MMM HH:mm:ss' -> 24 ago 12:34:56
'\Mon\t\h\: M' -> Month: 8
'HH:mm:ss.ffffzzz' -> 12:34:56.0000+08:00

 

而当culture被设置为en-us时，打印结果也将会作出相应变化。

====================缺省格式====================
8/24/2016 12:34:56 PM
====================标准格式====================
d -> 8/24/2016
D -> Wednesday, August 24, 2016
f -> Wednesday, August 24, 2016 12:34 PM
F -> Wednesday, August 24, 2016 12:34:56 PM
g -> 8/24/2016 12:34 PM
G -> 8/24/2016 12:34:56 PM
m -> August 24
o -> 2016-08-24T12:34:56.0000000
R -> Wed, 24 Aug 2016 12:34:56 GMT
s -> 2016-08-24T12:34:56
t -> 12:34 PM
T -> 12:34:56 PM
u -> 2016-08-24 12:34:56Z
U -> Wednesday, August 24, 2016 4:34:56 AM
y -> August 2016
====================自定义格式====================
'h:mm:ss.ff tt' -> 12:34:56.00 PM
'd MMM yyyy' -> 24 Aug 2016
'HH:mm:ss.f' -> 12:34:56.0
'dd MMM HH:mm:ss' -> 24 Aug 12:34:56
'\Mon\t\h\: M' -> Month: 8
'HH:mm:ss.ffffzzz' -> 12:34:56.0000+08:00

 

问题解决之后，再次回顾该案例，可以做出如下总结。

1. 对于测试人员，描述bug时应务必详尽准确，例如该问题只在pt-br上发生，其余语言均不重现。或问题再除了en-us的所有语言上均有发生。这类的信息异常重要，它将直接影响到后期bug triage的方向和root cause排查所花费的时间。

2. 对于开发人员，凡涉及到request date time的使用，务必明示统一格式，不能在ToString的时候采用缺省值。当然，也不要使用自定义的format string，具体原因请参见之前的文章《当Culture遇上DateTimeFormat》。