DatePicker - Max and Min

[Paul]

Hi there,

I have a query over the out of the box approach used to control the max and min properties of a MVC DatePicker. I am using the Q3 2014 release and Kendo validation with MVC 5.

Without applying the .Max() or .Min() attributes, here is what we have being rendered out of the box:

$(function () {
        $("#DOB").kendoDatePicker({
            "format": "d",
            "min": new Date(1900, 0, 1, 0, 0, 0, 0),
            "max": new Date(2099, 11, 31, 0, 0, 0, 0)
        });
    });

This does correctly apply the range to the picker element - it is not possible to use this to input a date outside this range. However, the effect of this on the keyboard input is altogether different.

• If I type in a date within the range, i.e. 01/01/2000, but then add an extra digit to the year, this will be automatically truncated. So 01/01/20000 becomes 01/01/2000.
• However, if I type in a date which falls outside the min/max range, i.e. 01/01/1800 and then add an extra digit, nothing happens.

Surely this approach is very inconsistent? Why have the autocorrect functionality at all if it is only applied within the range?

I have read other responses to similar queries (Kendo DatePicker Max and Min values not limiting text entry). The suggestion there was to make the input control read only to achieve the desired behaviour (meaning that only the picker can be used). Surely this isn't really acceptable from an accessibility point of view?

I would also have expected the date control to be able to enforce the Max and Min values which are part of its own API - for both keyboard and the picker? There is obviously some script running which recognises it is within or without the range - or else why do we observe the behaviour above?

Thanks,

Paul

[Alexander Popov]

Hello Paul,

Indeed, the Min and Max options are applied only on the DatePicker's calendar. The user's input is not restricted in any way and the DatePicker tries to parse it using the default or explicitly specified parseFormats after the focus has been lost. Since regular expressions are used along with the parseFormats there might be some scenarios where certain values are considered correct and others are not. You can either specify you own parse formats or use custom validation rules. The latter would allow you to parse and validate the input even before the widget does, so you can show error messages, clear the widget's value or anything else that seems appropriate for the scenario.

Regards,
Alexander Popov
Telerik