What's the best practice when dealing with a culture's limited range of supported DateTime values?

Question

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.

Thistledown

They are religious calendars, very hard to deal with since they are based on lunar observation. A month could be 30 days instead of 29 if it was cloudy. Future dates will change on the fly, note the HijriAdjustment property. Only convert the current date. – Recover

Would it be a bad idea to simply force a gregorian calendar, then? Or would that not be very usable. – Thistledown

I think you need to talk to your customer and find out more about their business practices. – Recover

That is a fair statement. However, I doubt it will ever come up. We're only supporting French and Spanish currently, and given our business no Arabic locales are likely. It won't even be selectable. I just figured I could set it up now, just in case, rather than run into issues later. But I guess that can't always be the case. – Thistledown

Answer 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.

Graiae