Question

I upgraded an MVC3 solution to MVC4. After the migration, the validator is broken.

My input date, if i select German as language, is “20.03.2013”. I get an validation error in MVC4, but not in MVC3. If i replace the format from “20.03.2013” to “20/03/2013” it works in MVC4, but not in MVC3 😉

I set the UI culture of the current thread to german. The output of the ResX values are in the correct language, so i know there should be no error with the culture., only for the site itself. The error messages are in english, but the site is in german.

I assume this means the validator uses the wrong UI Culture.

Here is the code i use.

[Required(ErrorMessageResourceName = "Error_DepartureDate", ErrorMessageResourceType = typeof(Resx.Query))]
public DateTime? DepartureDate { get; set; }

I assume there is something wrong with the default model binder, as the rendered html looks good:

data-lang="de" data-mindate="3" data-val="true" data-val-required="Bitte geben Sie das gewünschte Reisedatum des Hinflugs ein." id="DepartureDate" name="DepartureDate" tabindex="3" type="text" value="" 

I upgraded the Jscript to the sources that ship when you create a new Mvc application using the Visual Studio 2012 (SP1 is installed) templates. This had no impact.

I have a CultureModelBinder which reads the current culture out of the Session and sets the culture using a small helper function.

public static void UpdateThreadCulture(CultureInfo culture)
{
  Thread.CurrentThread.CurrentUICulture = culture;            
}        

The culture model binder is the default binder.

ModelBinders.Binders.DefaultBinder = new CultureModelBinder();
ModelBinders.Binders.Add(typeof(DateTime?), new DateTimeModelBinder());
// and many, many more

Maybe something changed in the execution order with mvc4 resulting the problem?

Update: The project uses .NET Framework 4.5 as target.

Update 2:

I have a combo box where the user can select 16 different languages, each might have it’s own specific formatting.

E.g.
DE-de -> DD.MM.YYYY;
en-en -> DD/MM/YYYY;
en-us -> MM/DD/YYYY

I just got a hint about setting the current culture, here is the proof it should be correct as it is. This code is not hit when the validators fail, it looks like it happens on the client side.

   public class DateTimeModelBinder : IModelBinder
    {
        private LogService _log = new LogService();

        public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
        {            
            object result = null;
            ValueProviderResult valueResult = bindingContext.ValueProvider.GetValue(bindingContext.ModelName);
            if (valueResult != null)
            {
                try
                {
                    var stateHandler = new StateHandler(controllerContext.HttpContext.Session);                    
                    result = valueResult.ConvertTo(typeof(DateTime?), stateHandler.Culture);                                       
                }
                catch
                {
                    try
                    {
                        result = valueResult.ConvertTo(typeof(DateTime?), CultureInfo.InvariantCulture);
                    }
                    catch (Exception ex)
                    {
                        _log.Error("DateTimeModelBinder parse exception", ex);
                        _log.KeyValue("AttemptedValue", valueResult.AttemptedValue);                                           
                    }                    
                }
            }
            return result;
        }
    }

and for completeness my culture model binder:

  public class CultureModelBinder : DefaultModelBinder
    {      
        public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
        {
            StateHandler stateHandler = new StateHandler(controllerContext.HttpContext.Session);
            Helper.UpdateThreadCulture(stateHandler.Culture);

            return base.BindModel(controllerContext, bindingContext);
        }        
    }

Update: Maybe there is a correlation to this problem:
http://connect.microsoft.com/VisualStudio/feedback/details/705643/a-data-val-date-attribute-is-generated-for-time-fields-in-asp-net-mvc-4

Update:
Read the following article:
http://weblogs.asp.net/scottgu/archive/2010/06/10/jquery-globalization-plugin-from-microsoft.aspx

tried the following out:

Loaded the scripts in the following order:

/Scripts/jquery-1.8.3.min.js
/Scripts/globalize.js
/Scripts/cultures/globalize.cultures.js
// and much more other scripts...

added the call. the output was correctly “DE”.

        var currentLanguage = $("#DepartureDate").attr("data-lang");
        alert(currentLanguage);       
        $.preferCulture(currentLanguage);

No affect to the validators…

Answer 1

The point is that Mvc3 doesnt validate at all dates on the client side that is the point. You just set the cultrure on the server side….but your culture settings are not reflected at all on the client side…at least the Mvc engine doesnt do it automatically. The only way to handle properly dates and numbers on the client side with cultures that differs from English is to use a a javascript globalization library that is able to parse properly dates in all cultures, and to set the client side culture equal to the server side culture, then you have to redefine properly all validation methods to use globalized functions.
Please read this post of my blog that clarifies how to handle properly globalization on the client side: http://www.dotnet-programming.com/post/2011/12/14/Globalization-Validation-and-DateNumber-Formats-in-AspNet-MVC.aspx

Moreover, please dont confuse CurrentCulture with CurrentUICulture CurrentUICulture doesnt affect at all the way numbers or dates are handled, but only the resource files containing culture specifi resources such as localized strings.

Finally, it is very unefficient to set the culture in the model binder, since the model binder is a recursive function so it si called hundreds of times during model reconstruction, and the culture setting operation is not a simple variable setting operation but it has a not negligible cost. It is better to write a global controller filter to handle culture setting (I always do this way) so the operation is performed just once per request