Last Updated: 05 Aug 2021 09:40 by ADMIN
Created on: 30 Jul 2021 15:42
Category: DatePicker
Type: Bug Report
RadDatePicker date parsing issue when using both DateInput-DisplayDateFormat and DateInput-DateFormat

I am using a RadDatePicker in my page like this

<html xmlns="">
    <head runat="server">
        <title>Test Page</title>
        <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" >


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,


1 comment
Attila Antal
Posted on: 05 Aug 2021 09:40

Hi Greg,

We have double-checked the documentation and tested the DatePicker in different scenarios. It seems to work as intended.

There are two important articles that you will need to consider.

1. How to Format Dates when using the DateFormat or DisplayDateFormat properties. See Formatting Dates

There we noted that: "When you set the DateFormat or DisplayDateFormat property to one of these format characters, the RadDateInput control automatically expands it into a format string built of the patterns listed below. Thus, changing the Culture property after setting the DateFormat or DisplayDateFormat property to one of these format characters will not change the overall pattern, but only the interpretation of symbols within the pattern."

Having that said, the input value should be in the exact format you specify in the DataFormat property. If you set it to "yyyyMMddd" the input value should be "20210704" for July 4th, 2021. First four digits for the year, the next two digits for the month, and the last two digits for the day.


2. The Parsing Dates article explains how the built-in parsing mechanism works with and without custom DateFormat. Here you can understand how the values from the input are interpreted and parsed.


Since this issue is not considered to be a Bug, the Bug report will be declined. In case you would like more clarification on the Documentation, please submit a "General Feedback" and let us know which part is misleading, and we will clarify that.


Attila Antal
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.