Parsing problem while typing in date

[Sam]

Hi, we're experiencing what looks like a bug in the RadDatePicker control.

I've set the culture in the App.xaml.cs file, and the DatePicker correctly displays the dates as intended:

/// <summary>
    /// The main application class.
    /// </summary>
    public partial class App
    {
        #region Constructor
        /// <summary>
        /// Initializes a new instance of <see cref="App" />.
        /// </summary>
        public App()
        {
            StyleManager.ApplicationTheme = new Windows8Theme();
            InitializeComponent();

            Windows8Palette.Palette.AccentColor = (Color)Resources["AccentColor"];

            ConfigureCulture();
        }
        #endregion

        #region Private Methods
        /// <summary>
        /// Configures the culture for the application.
        /// </summary>
        private static void ConfigureCulture()
        {
            // set the default culture to English (AU)
            // ReSharper disable UseObjectOrCollectionInitializer
            var culture = new CultureInfo("en-AU");

            // ReSharper restore UseObjectOrCollectionInitializer
            // long date format is used on date controls ("D")
            culture.DateTimeFormat.LongDatePattern = "ddd d-MMM-yyyy";

            // short date format is used in grids ("d")
            culture.DateTimeFormat.ShortDatePattern = "dd-MMM-yy";

            Thread.CurrentThread.CurrentCulture = culture;
            Thread.CurrentThread.CurrentUICulture = culture;
        }
        #endregion
    }

However when a user types in '25-9-13', as soon as they type the '9', the date is shown as  'Mon 1-9-2025' in the tooltip, ie, it suddenly flips the format to yy-mm-dd.

Note that this is not a problem in the corresponding Silverlight control - typing '25-9' correctly shows 'Wed 25-Sep-2013' in the tooltip.

Is this a bug, or something that we can resolve somehow?

Thanks

Sam

[Konstantina]

Hi Sam,

Thank you for reporting this issue to us.

Indeed, this is a bug in the DateTimePicker for WPF. I have logged it in PITS, so that you could track its status and see when it is going to be fixed.
Your Telerik points have been updated for your involvement.

Regards,
Konstantina
Telerik

[Konstantina]

Hi Sam,

Meanwhile, I found a work-around for the problem: in order to make it work the Separator property of the DateTimeFormat should be set, alongside the other properties: 

culture.DateTimeFormat.DateSeparator = "-"

We will consider whether is intuitive for the developers to have it explicitly set, or to be extracted from the format set.

Regards,
Konstantina
Telerik

[Sam]

Thanks Konstantina, that works perfectly, even when the user types a different separator in (such as /).

Cheers,

Sam

[Alper]

Hi Konstantina,

I have searched the forums but could not find an answer. This issue is the only issue I can find that is close to the problem I have.

There is a similar issue when the short date format is set to yyyy-MM-dd. In order to avoid any confusion, we set the date format as yyyy-MM-dd. However, when the user types 1/2/2014 - or something similar - 2 is considered as day, 1 is considered as month. We would like to make it variable depending on the user's locale.

The issue gets worse if we try the example above. If the user tries to type 25/9/2013 - or with other separators, it is not accepted. What do you recommend to solve the issue?

Kind Regards,
Alper

[Konstantina]

Hi,

Let me explain how the parsing of the DatePicker is working:
1) if you use the default parsing it always takes the first number entered as the day and the second as the month. The others left is trying to parse as the year. Only at the end when the date is parsed it formats it to fit the ShortDateFormat set.
2) if you set the AllowParsingWithoutSeparator=True property the parser will be able to parse the numbers in the exact same order as the ShortDateFormat set. More information how this parser is working you could find in this help article: http://www.telerik.com/help/wpf/raddatetimepicker-features-parsing-without-separators.html

Regards,
Konstantina
Telerik