問題描述

這是一個奇怪的...

我剛剛看到一個(之前通過的)測試失敗，因為日期的字符串表示中有多余的空格.有問題的測試以前在 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模板網！