为什么我的本地机器可能会错误地格式化国际日期？

Question

这里有一个奇怪的...

我刚刚看到一个（以前通过的）测试失败，因为日期的字符串表示中有多余的空格。有问题的测试之前已经在 CI 和我的本地机器上通过，但现在失败（在我的本地机器上），因为日期段之间有多余的空格。

以下 MCVE 表现出相同的行为：

using System;
using System.Globalization;

public class Program
{
    public static void Main()
    {
        var date = new DateTime(2018, 01, 31);
        var format = "d/M/yyyy";
        var skSK = new CultureInfo("sk-SK");
        Console.WriteLine(date.ToString(format, skSK));
    }
}

在大多数地方（包括.NET Fiddle），这会正确返回：

31.1.2018

但是在我的机器上，我现在得到：

31. 1. 2018

注意多余的空格！

我确信这在本周早些时候在我的本地 PC 上按预期工作，因为我将项目与此测试一起用作一些覆盖工具实验的起点。当我今天下午恢复该实验时，由于新的测试失败，不再生成覆盖文件。

我的 PC 上发生了什么变化会导致这种损坏的行为？

Answer 1

在 Windows（与许多其他系统一样）中，区域设置日期/时间格式的来源是Unicode 通用区域设置数据存储库 (CLDR)，它为软件开发人员和语言学家提供特定的国际化和本地化支持。

有意义的用户的简短列表：

• 微软（Windows、Office、Visual Studio 等）
• Apple（macOS、iOS、watchOS、tvOS、Apple 移动设备支持和 Windows 版 iTunes；
• Google（网页搜索、Chrome、Android、Adwords、Google+、Google 地图、Blogger、Google Analytics）
• IBM（DB2、Lotus、Websphere、Tivoli、Rational、AIX、i/OS、z/OS）
• 亚马逊

请参阅 Localizations: Locale Explorer的在线数据浏览器。

本地化为sk-SK文化的 Short Date 格式d. M. yyyy是此存档中列出的格式。对于所有操作系统（Windows 7 到 Window 10）都是一样的。

与 MS 开发人员相关的博客：Locale Builder 和芬兰语或其他语言环境。

Fiddler或其他在线代码运行器服务不是这个问题的比较来源。
区域设置因系统而异。此外，这些国际格式会随着时间而变化，并取决于系统收到的更新（如果它收到这些更新）。

在 Windows 7 和 Windows 10 中，sk-SK文化的默认短日期格式是d. M. yyyy.
但是DateTime如果进一步解析格式列表，则模式不匹配。

string format = CultureInfo.CreateSpecificCulture("sk-SK")
                           .DateTimeFormat.GetAllDateTimePatterns()[1]; 

在 Windows 7 中，DateTimePatterns列表中的第二个元素是d.M.yyyy
在 Windows 10 中，相同索引处的元素是：dddd d. MMMM yyyy

Windows 更新可能会更改任何区域设置的默认模式（无需明确通知）。
据了解，应用程序必须为特殊情况提供解析手段。或者在格式化时参考用户区域设置，而不尝试强制内部使用的特定模式。
日期/时间格式应仅用于演示。区域设置和用户设置决定了该格式。系统用户可以决定使用与默认区域设置不同的格式。

此 GitHub 存储库包含 CLDR 数据库的更新 JSON：
CLDR Date Modern

同样有趣的是，用于 API 国际化的 ECMAScript 参考：
ECMAScript® 2017 国际化 API 规范

MSDN 全球化和本地化最新指南（UWP 相关）：
全球化和本地化
全球化您的日期/时间/数字格式
使用多语言应用程序工具包 4.0