处理文化中受支持的日期时间值的有限范围时，最佳实践是什么？
我目前正在经历一个项目（.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 非常相似，但支持的最小和最大日期更加宽松。这是很多人都会遇到的问题吗？对于这个特定问题，我找不到太多建议。我不愿意在没有任何建议的情况下一时兴起简单地更改这些文化中使用的默认日历。
I'm currently going through the globalization process for a project (a .net mvc2 app), and globalization is a bit new to me. I've noticed that DateTime.ToString(), when formatted for some cultures, can cause an ArgumentOutOfRangeException for values too far in the past or future. In particular, the calendars used for "ar" and "ar-SA" (UmAlQuraCalendar) have very limited minimum and maximum supported dates. When using UmAlQuraCalendar, any date before April 1930 or after May 2029 will cause this. This is easily observable:
DateTime.ParseExact("1900", "yyyy", CultureInfo.InvariantCulture).ToString("G", new CultureInfo("ar"));
Forgive my ignorance on the subject, but I'm wondering what the best practice is here. I would like it if I could represent dates earlier than 1930 without having to add exception handling every time I print a date, but I would also like to respect the user's culture. Is the best option here to switch calendars for these cultures? It seems from some googling that the the optionally provided HijriCalendar is very similar to UmAlQuraCalendar, but with much more relaxed minimum and maximum supported dates. Is this a problem a lot of people encounter? I haven't been able to find much advice this this particular issue. I'm hesitant to simply change the default calendar used in these cultures on a whim, without some advice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为了获得全球化的最佳结果，请在应用程序的所有区域中严格遵守文化不变的数据表示，表示层（人机交互）除外；并在表示层中为需要呈现给人类或由人类直接输入的所有内容添加一致的翻译层。
具体而言，关于日历：许多全球应用程序严格遵守公历（尽管人类可见的格式当然是本地化的）；有些确实支持在某些国家/地区具有官方地位的其他一些日历，但话又说回来，这是在表示层上实现的，对应用程序的影响最小，并且只有在满足这些市场的实际情况时，或者甚至在生产部署之后该地区已经启动。
For best results with globalization in general, strictly stick to culture invariant data representation in all areas of your application, except for the presentation layer (human interaction); and add a consistent translation layer in the presentation layer for everything that needs to be presented to a human, or was directly entered by a human.
Regarding calendars in specific: many global applications strictly stick to the Gregorian calendar (although the human-visible formatting is, of course, localized); some do support a few other calendars that have official status in some countries, but then again, this is implemented on the presentation layer with minimal impact on the application, and only when it becomes realistic to address those markets, or even after production deployments in the area have already started.