.net - 处理文化中受支持的日期时间值的有限范围时,最佳实践是什么?

标签 .net datetime globalization cultureinfo

我目前正在经历一个项目(.net mvc2 应用程序)的全局化过程,全局化对我来说有点新鲜。我注意到DateTime.ToString()当针对某些区域性进行格式化时,对于过去或将来太远的值可能会导致 ArgumentOutOfRangeException。特别是,用于“ar”和“ar-SA”( UmAlQuraCalendar ) 的日历具有非常有限的最小和最大支持日期。使用 UmAlQuraCalendar 时,1930 年 4 月之前或 2029 年 5 月之后的任何日期都会导致此问题。这很容易观察到:

DateTime.ParseExact("1900", "yyyy", CultureInfo.InvariantCulture).ToString("G", new CultureInfo("ar"));

请原谅我对这个主题的无知,但我想知道这里的最佳实践是什么。如果我可以表示早于 1930 年的日期,而不必在每次打印日期时添加异常处理,我会很高兴,但我也想尊重用户的文化。这是针对这些文化切换日历的最佳选择吗?从一些谷歌搜索看来,可选提供的 HijriCalendar与 UmAlQuraCalendar 非常相似,但支持的最小和最大日期更加宽松。这是很多人都会遇到的问题吗?对于这个特定问题,我找不到太多建议。我不愿意在没有任何建议的情况下一时兴起简单地更改这些文化中使用的默认日历。

最佳答案

为了获得全局化的最佳结果,请在应用程序的所有区域中严格遵守文化不变的数据表示,表示层(人机交互)除外;并在表示层中为需要呈现给人类或由人类直接输入的所有内容添加一致的翻译层。

具体而言,关于日历:许多全局应用程序严格遵守公历(尽管人类可见的格式当然是本地化的);有些确实支持在某些国家/地区具有官方地位的其他一些日历,但话又说回来,这是在表示层上实现的,对应用程序的影响最小,并且只有在满足这些市场的实际情况时,或者甚至在生产部署之后该地区已经启动。

关于.net - 处理文化中受支持的日期时间值的有限范围时,最佳实践是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8409565/

相关文章:

c# - 如何在单元测试中将 FakeItEasy 与 HttpClient 一起使用?

c# - 将现有 .NET 项目部署到 Bluemix

html - 无法加载资源 : the server responded with a status of 404 (Not Found) error in server

.net - 使用 ASP.NET 和全局化获取 WCF 服务中的浏览器文化

c# - 建议创建语言设置?

c# - 从网络服务写入文件

php时间处理NULL为00 :00:00

python - 如果日期间隔大于 N 秒,则用最后一个值填充列表

java - 在java中将UTC日期和时间添加到数据库

c# - Windows 窗体中数字键盘小数键的区域性特定处理