Parsing a date time in november using bg-BG culture and dd-MMM-yyyy format.

Question

I am working on localization code for dates and times, and I am seeing an odd behavior when the culture is set to Bulgarian, and the date I pass in is in November.

Essentially, I am trying to call:

if (DateTime.TryParse(theDateToParse, formatProvider, DateTimeStyles.None, out localDate))
{ //Do code work here }

Where theDateToParse = 15-Нов-2013 15:20:39 (This value comes from a jquery datepicker, with a time appended to it, and is November 15th) and the formatProvider is the bg-BG culture information.

Testing other values, and other cultures, it would appear that the problem is specific to any date in November in the bg-BG culture. Additionally, if I change it to use the full month name, it can parse it correctly.

To test this theory, I went the other way around and created a dateTime object for a day in each month and converted them to strings using the dd-MMM-yyyy format. For each month I got a shortened month name, except for November, where I got a full month name.

I was just looking to see if anyone had any background around why this is happening, or had any clever solutions to make this case work. I have spent some time searching, and I can't even find someone that has come across the same problem.

Answer 1

Running this code:

var culture = CultureInfo.CreateSpecificCulture("bg-BG");
foreach (var name in culture.DateTimeFormat.AbbreviatedMonthNames)
    Debug.WriteLine(name);

Gives these month name abbreviations:

яну фев мар апр май юни юли авг сеп окт ное дек

It would seem that .Net has the abbreviation for November in Bulgarian to be "ное", not the "Нов" string in your input.

I don't speak Bulgarian, but Google Translate accepts "ное" as "November", but "Нов" is translated to English as "new". So my guess is that the source data is incorrect.

The best solution is to never transmit dates as localized strings between client and server. Instead, use an ISO8601 format, such as 2013-11-15T15:20:39 .