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

问题描述

这是一个奇怪的...

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

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

使用系统；使用 System.Globalization；公开课程序{公共静态无效 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 上发生了什么变化会导致这种损坏的行为?

在 Windows(和许多其他系统一样)中，Locale 日期/时间格式的来源是 Unicode Common Locale Data Repository (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)
• 亚马逊

查看本地化的在线数据浏览器:Locale Explorer.

短日期格式，本地化为 sk-SK 文化为 d.M. yyyy，是这个档案中列出的那个.所有操作系统(Windows 7 到 Window 10)都一样.

与 MS Developer 相关的博客:Locale Builder 和芬兰语或其他语言环境.

Fiddler 或其他在线代码运行服务不是这件事的比较来源.
区域设置因系统而异.此外，这些国际格式会随着时间而变化，并取决于系统接收到的更新(如果它完全接收到这些更新).

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

字符串格式 = CultureInfo.CreateSpecificCulture("sk-SK").DateTimeFormat.GetAllDateTimePatterns()[1];

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

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

此 GitHub 存储库包含 CLDR 数据库的更新 JSON:
CLDR 日期现代

API 国际化的 ECMAScript 参考也很有趣:
ECMAScript® 2017 国际化 API 规范

MSDN 最新的全球化和本地化指南(UWP 相关):
全球化和本地化
全球化您的日期/时间/数字格式
使用多语言应用工具包 4.0p>

Here's a weird one...

I've just seen a (previously passing) test fail because of extra spaces in a string representation of a date. The test in question has previously passed in CI and on my local machine, but is now failing (on my local machine) because of extra spaces between segments of the date.

The same behaviour is exhibited by the following 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));
    }
}

In most places (including .NET Fiddle) this correctly returns:

31.1.2018

But on my machine, I now get:

31. 1. 2018

Note the extra spaces!

I'm confident that this was working as expected on my local PC just earlier this week, as I was using the project with this test in as a starting point for some experimentation with coverage tools. When I've resumed that experimentation this afternoon, the coverage file is no longer being produced due to the newly failing test.

What could have changed on my PC to cause this broken behaviour?

In Windows (like many others System), the source for the Locale date/time formats is the Unicode Common Locale Data Repository (CLDR), which provides internationalization and localization support specific for software developers and linguists.

A Short list of meaningful users:

• Microsoft (Windows, Office, Visual Studio etc.)
• Apple (macOS, iOS, watchOS, tvOS, Apple Mobile Device Support and iTunes for Windows;
• Google (Web Search, Chrome, Android, Adwords, Google+, Google Maps, Blogger, Google Analytics)
• IBM (DB2, Lotus, Websphere, Tivoli, Rational, AIX, i/OS, z/OS)
• Amazon

See the Online data explorer of the Localizations: Locale Explorer.

The Short Date format, localized to the sk-SK culture as d. M. yyyy, is the one listed in this archive. It's the same for all OS (Windows 7 to Window 10).

A MS Developer related blog: Locale Builder and Finnish or other locales.

Fiddler or other Online code-runners services are not a source of comparison on this matter.
Locales are different from system to system. Also, these international formats change over time and depend on the updates that a system receives (if it receives these updates at all).

In Windows 7 and Windows 10, the default Short Date format for the sk-SK Culture is d. M. yyyy.
But the DateTime patterns do not match, if the formats list is parsed further.

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

In Windows 7, the second element in the DateTimePatterns list is d.M.yyyy
In Windows 10, the element at the same index is: dddd d. MMMM yyyy

A Windows update may change the default pattern for any of the Locales (without explicit notification).
It's understood that applications must provide parsing means for special cases. Or refer to the user Locale settings when formatting, without trying to force a specific pattern for internal uses.
Date/Time formats should be used for presentation only. The Locale and the user settings determine that format. An user of a System may decide to use a different format than the default Locale.

This GitHub repository holds an updated JSON of the CLDR database:
CLDR Date Modern

Also interesting, the ECMAScript reference for API internationalization:
ECMAScript® 2017 Internationalization API Specification

MSDN latest guidelines for Globalization and localization (UWP related):
Globalization and localization
Globalize your date/time/number formats
Use the Multilingual App Toolkit 4.0

这篇关于为什么我的本地机器可能会错误地格式化国际日期?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持html5模板网！