 
	
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
