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
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