Invalid Leap Year Day Value Being Changed On Focus Loss

[AGB]

Hi Guys,

I have just tripped over an issue whereby an invalid leap year day value is being automatically changed when the control losses focus.

To illustrate the problem I have created the following

        http://dojo.telerik.com/ePIQE
        
If you run this dojo and enter 29/02/2001 then tab to second control the value is changed to 29/02/2020.

The same effect is not seen when entering 30/02/2001 and then tabbing away so it would appear to be related to the 29 Feb.

I have looked through the documentation and the forums for any information relating to this issue but have so far drawn a blank.

Therefore I would be most grateful if someone could take a look and advise.

Thanks
Alan

[Stefan]

Hello Alan,

The described result is expected, because of the second parsing format dd/MM/yy:

'29/02/20' -> "dd/MM/yy" -> 29/02/2020

In this scenario using the combination of the two formats can create similar issues.

Also, please have in mind that as this is not a valid date the DatePicker will still accept it, but the value will be null, and a custom validation can be used.

Also, I can suggest our new DateInput widget which has validation for invalid dates:

http://demos.telerik.com/kendo-ui/dateinput/index

http://docs.telerik.com/kendo-ui/controls/editors/dateinput/overview

I hope this is helpful.

Regards,
Stefan
Telerik by Progress

[AGB]

Hi Stefan,

Thanks for coming back to me.

> because of the second parsing format dd/MM/yy

That does not make sense because

    29/02/2001 does not match the format dd/MM/yy
    
so it should never be parsed as valid and auto formatted to 29/02/2020

> this is not a valid date the DatePicker will still accept but the value will be null

I'm happy with this and my code handles it, but what I'm not happy with is the control parsing dates as a valid format when they are clearly not.


> I can suggest our new DateInput

I have looked at the new DataInput control but

a) Our users what to enter dates via the keyboard or date picker

b) When using the keyboard they want to type dd/MM/yyyy, dd-MM-yyyy, ddMMyyyy.
   But the DateInput forces the use of a specific separator
   
c) They would be a revolt by our users because your implementation does not handle the entering of dates in the format dd/MM/yyyy easily.

For example if you have the control set to have an initial date of 01/02/2017

             $("#dateinput").kendoDateInput({
             value: new Date(2017, 1, 1),
            format: "dd/MM/yyyy",
            });
            
and the user wants to update the date to 31/03/2018 via the keyboard they have to

     cursor right or hit /
     enter 03
     cursor left
     enter 31
     cursor right or hit /
     cursor right or hit /
     enter 2018
     
All they want to do is enter 31032017
    
Regards
Alan

[Stefan]

Hello Alan,

Regarding the questions:

- DatePicker: currently this is the expected behaviour when the parsing format is used dd/MM/yy because the pasted value is spliced to 29/02/20 and passed in the widget.

In this scenario, I can suggest submitting a feature request for changing the parsing behaviour, and based on its popularity among the community on which is the expected result we may implement it in a future release:

http://kendoui-feedback.telerik.com/forums/127393-kendo-ui-feedback/category/170289-date-time-editors

- DateInput: Indeed the DateInput widget expects more strict inputs, as this will ensure that the entered values are valid.

Regards,
Stefan
Telerik by Progress

[AGB]

Hi Stefan,

Thanks for the reply but I think we will have to differ on both points

- DatePicker

    To me this is a bug in that a 10 digit input value should never match a 8 digit mask

- DateInput

    By making the data input more strict you have thrown out usability for data input clerks in the real world

Anyway now that I know the limitations of both controls I can look for alternative solutions to the problems.

Regards
Alan

[Stefan]

Hello Alan,

I will forward this to our developer's team for further investigation, as every feedback is highly appreciated and can help us to improve our widgets.

Thank you for understanding.

Regards,
Stefan
Telerik by Progress