Declined
Last Updated: 10 Jun 2021 11:55 by ADMIN

There is a problem with the rendering of the RadDateInput when RenderMode is set to Lightweight when on the same page we have a RadNumericTextBox with RenderMode != LightWeight

 

This is the issue when RadDateInput RenderMode="Lightweight" and RadNumericTextBox with RenderMode = "Classic"

 

The issue does not appear when all controls are in Lightweight mode

Declined
Last Updated: 05 Aug 2021 09:40 by ADMIN

I am using a RadDatePicker in my page like this

<html xmlns="http://www.w3.org/1999/xhtml">
    <head runat="server">
        <title>Test Page</title>
    </head>
    <body>
        <form id="Form1" runat="server">
            <telerik:RadScriptManager runat="server"></telerik:RadScriptManager>
            <telerik:RadDatePicker runat="server" ID="RadDatePicker1" 
                RenderMode="Lightweight" Culture="English (United States)" 
                DateInput-DisplayDateFormat="d" DateInput-DateFormat="yyyyMMdd" >
            </telerik:RadDatePicker>
        </form>
    </body>
</html>

 

If the culture is set to fr-FR, the DateInput box displays the date in dd/MM/yyyy format and when the input box has focus, the date is converted to yyyyMMdd format for entry.  It also allows for other entry formats such as dd/MM/yyyy and the many other formats documented here DateInput - Parsing Dates.  This is much improved over the legacy input we have been using in our application which has required the users to always enter a date as yyyyMMdd as it allows both the established input format as well as their culture specific format.

The issue I am having is if the culture is set to en-US as above.  Like in the previous example, dates are formatted in the culture specific format, this time mm/DD/yyyy but can be input as yyyyMMdd.  However, if the date is entered in as a month/day/year triplet in the culture's format of mm/DD/yyyy, it is parsed as if it was entered in the DD/mm/yyyy format without consideration to the culture setting. So entering 7/4/2021 for July 4th 2021 in the en-US culture, the date becomes 4/7/2021 or April 7th 2021.

According to the DateInput Parsing Dates document linked above "a month/day/year triplet: a month can be both a numeric value or a month name. The order of the parts in the triplet is culture specific."  This does not appear to be the case.  It seems that by using the DateInput format, a month/day/year triplet is no longer applying the culture during parsing.

Is this a bug in the date parsing where culture isn't being used for this scenario?  Does the documentation need to be updated to clarify the parsers behavior when DateInput-DateFormat is used?

 

Please advise,

Greg