Question

如果我运行此代码......

var cults = CultureInfo.GetCultures(CultureTypes.SpecificCultures);

var exam = from c in cults
            from p in c.DateTimeFormat.GetAllDateTimePatterns('d')
            select new { Culture = c.DisplayName, Format = p };

...我可以看到Windows或.net认为是不同语言环境的习惯或标准的各种“短日期”格式的转储。

但是，如何才能独立确认或验证这些值？我认识到微软已经投入了数十万小时的时间来审查这些日期格式列表。我实际上并不认为有任何错误。但我还是想知道微软本身是如何进行验证的呢？他们只是阅读MLA Formatting and Style Guide的每个特定于语言环境的演绎吗？

让我们再仔细看看。根据我上面写的代码，下面是美国已知或习惯的“短”日期格式列表：

M/d/yyyy
M/d/yy
MM/dd/yy
MM/dd/yyyy
yy/MM/dd
yyyy-MM-dd
dd-MMM-yy

请注意，格式字符串“dd / MM / yy”不存在。这意味着美国公民不会以2014年8月1日的“1/8/2014”形式撰写。我同意这一点。然后是日本：

yyyy/MM/dd
yy/MM/dd
yy/M/d
yyyy/M/d
yy/MM/dd' ('ddd')'
yy/M/d' ('ddd')'
yyyy/MM/dd' ('ddd')'
yyyy-MM-dd

显然，该语言环境没有习惯使用d / M / yy或M / d / yy。很高兴知道，但再次......我将如何独立验证.net向我呈现的这些选项？

我问的一个原因是因为我正在与全球化工程师讨论，他们不确定他们是否相信.net产生的这些价值观。如果他们不喜欢微软，那么“现在是什么”来说服他们呢？

Answer 1

与全球化工程师交谈时考虑这一点的最佳方式是，微软已投入这一空间，以避免每个开发人员重做相同数量的工作。报告问题时会更新此数据，如果您确定存在问题，则可以报告。 common locale data repository是类似数据的另一个来源，您也可以针对此提交错误。如果他们担心控制，您始终可以选择使用自定义的自定义格式模式作为资源，以便它们可以根据语言而有所不同。您可以使用Microsoft或CLDR中的值预先设置此种子。

验证特定于语言环境的＃34;习惯性＆＃34;日期格式

1 个答案: