Incorrect default DateTimeFormat.ShortDatePattern for culture es-DO

Question

I live in the Dominican Republic and have been developing applications using the .NET Framework for a couple of years. Usually, I create localized applications for this specific culture (es-DO) and it's very helpful for me to use the built-in .NET globalization mechanism. In the case of a web application, I usually define the global culture in the Web.Config:

<globalization culture="es-DO" uiCulture="es-DO" />

But there's an issue in the ShortDatePattern of the DateTimeFormat for that culture that has caused confusion for me and fellow developers. For unknown reasons, the default ShortDatePattern format is d/M/yy while in reality the regular formats used in this country are dd/MM/yyyy and dd-MM-yyyy like most other Spanish-speaking countries (which are, by the way, configured correctly).

I created a small console application to illustrate better:

I have confirmed the same behavior in several PCs and even publishing my web apps to hosting providers like Windows Azure.

I have been looking for information on the subject, but it seems like it's a very localized issue regarding this specific (and not-so-popular I may add) culture and therefore it's very hard to find any documentation at all.

Basically, I have two questions regarding this:

• How do they know the correct culture format? They did any kind of study? Is this documented somewhere that I can look at? And,
• Is it possible to fix this issue without having to specify the desired format everywhere in my application/s?

EDIT

This has now been reported as a bug in Microsoft Connect and Visual Studio Forums.

Answer 1

.Net gets its data from Windows (at least it has since .Net 4.0 -- and even in prior versions the only difference is in the final default data). The short date pattern is returned by a call to GetLocaleInfoEx with the LCTYPE of LOCALE_SSHORTDATE.

The process for returning the appropriate data is effectively (there are optimizations in place) to check to see if the locale name requested (in your case "es-DO") is the current user locale and if so to check and see if there is a user requested override for that value. If there is then it is returned, if not, then if there is a custom culture installed that replaces the default data, that data is returned. Finally, the default supplied data is returned.

The default data is part of an internal database that is maintained by Microsoft. That database has been maintained for ages and periodically reviewed by in country language experts. If you see something that doesn't seem right and you are a native speaker, you should report it as a bug. Sometimes there are legitimately more than one way to express the data and the speakers themselves are split as to which is the "right" one. That is why users can override the defaults for the user locale.

There are a couple of options for working around this:

1. Change your user default for the short date (language and region control panel) when es-DO is the user locale
2. Create a custom culture that replaces es-DO
3. In your code, select a pattern that contains a 4 digit year. (The pattern you expect is in the data, but it isn't the default)

If you choose to do the last, you will want to look at the DateTimeFormatInfo.GetAllDateTimePatterns method. Use the 'd' format to get all the short date formats and then you can find the first one containing "yyyy".

Answer 2

How do they know the correct culture format? They did any kind of study? Is this documented somewhere that I can look at?

• There is a team at Microsoft that maintains this data. Their internal studies are not published directly (that I know of), but this is implied by statements such as the following from this article:

  Individual property values are subject to change and revision over time, as data is corrected, better data becomes available, or culture-specific conventions change.

• There are other public sources of this data, specifically the Unicode CLDR. But it is not clear whether or not Microsoft uses this information in their determination. A quick check of the CLDR data for es_DO shows no variations from es_419 (Latin American Spanish), even that shows no variation of the datetime formats from es (general Spanish) where the format is defined correctly. So if Microsoft uses this at all, they certainly don't use it verbatim or you would see the correct results.

• You may be able to find something buried in one of these blogs, or reach out to the authors directly:

  • MSDN Global Developer Blog
  • Shawn Steele's Blog
  • Michael Kaplan's Blog
  • Kieran Snyder's Blog
    
    

• You might want to report the discrepancy to Microsoft.

Is it possible to fix this issue without having to specify the desired format everywhere in my application/s?

• Sure, just change the culture on the current thread:

  var currentCulture = Thread.CurrentThread.CurrentCulture;
  if (currentCulture.Name == "es-DO")
  {
      var culture = (CultureInfo) currentCulture.Clone();
      culture.DateTimeFormat.ShortDatePattern = "dd/MM/yyyy";
      Thread.CurrentThread.CurrentCulture = culture;
  }
  

• In a web app, you can do this in the Application_BeginRequest of your global.asax.cs file, and it will carry throughout your application.

Answer 3

You could try using the tools to create custom cultures.

I haven't done this in detail before but it looks like you can override what es-DO points to.

Note that this will only cover the server side of things, not client side (javascript).