Steps to replicate the issue:
- Set the computer's Time Zone to CST (Central Standard Time) which is UTC -6:00.
- Enable Daylight Saving
- Open VS and create a new Page with a DatePicker in it (basic settings)
- Select the date "4/1/2023" and picking the time "2:00 AM" jumps to "3:00 AM"
Important: for the Time Zone changes to have effect, the Visual Studio solution has to be closed/re-opened.
We are in the process of upgrading our controls to Telerik. We had noticed a behavior that we did not want to happen, this was related to DatePicker control changing the value of the date if incorrect format was entered, we solved this by having EnableSmartParsing to false in our Telerik Theme so that it applies to all DatePicker controls.
Now we have some instances of date controls that are defined with specific DateFormat/DisplayDateFormat like below:
<telerik:RadDatePicker ID="dpId" DateInput-DisplayDateFormat="y" DateInput-DateFormat="y" runat="server"></telerik:RadDatePicker> or
<telerik:RadDatePicker ID="dpFrom" DateInput-DateFormat="MM/yyyy" DateInput-DisplayDateFormat="MMM, yyyy" runat="server"></telerik:RadDatePicker><telerik:RadDatePicker runat="server"
DatePopupButton-Visible="false"
PopupDirection="BottomLeft"
ShowPopupOnFocus="true"
DateInput-EnabledStyle-HorizontalAlign="Left"
DateInput-EnableSmartParsing="false"
MinDate="0001-01-01">
</telerik:RadDatePicker>
Test Environment:
OS: Windows_11
Tool: Colour Contrast Analyser (Version 3.1.2) Repro Steps: 1. 1.Open URL: https://demos.telerik.com/aspnet-ajax/datepicker/overview/defaultcs.aspxpage in Edge Browser.
Actual Behavior:
Luminosity contrast ratio for 'selected date' on Calander is 1.6:1 which is less than 4.5:1.
Expected Behavior:
Contrast ratio for the text must be greater than or equal to 4.5:1.
No direct way to select the prev/next month and year buttons - While the calendar is open and focused, note that there is no way to focus and use the month and year changing buttons in the calendar header
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
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
Markup to reproduce:
<telerik:RadDatePicker Runat="server" MaxDate="11/10/2020" MinDate="11/10/2020" EnableKeyboardNavigation="true" EnableAriaSupport="false"></telerik:RadDatePicker>Open the popup calendar and try to navigate with the arrow keys. JavaScript error is thrown
1) There is no element with the id or name as the value of the aria-controls attribute of the dateinput button with enabled ARIA support.
2) The aria-valuemin and aria-valuemax attribute are not valid on role=textbox
To fix these, the following workarounds can be used
Option 1: OnClientLoad event of the DateInput element inside the DatePicker
function DatePickerOnClientLoad(sender) {
setTimeout(function () {
$telerik.$(sender.get_element()).parent().find("[role=button][aria-controls]").removeAttr("aria-controls");
$telerik.$(sender.get_element()).removeAttr("aria-valuemin").removeAttr("aria-valuemax")
})
}
Option 2: using Sys.Application.Load event
function pageLoadHandler() {
$telerik.$("[role=button][aria-controls]");
$telerik.$("[role=textbox]").removeAttr("aria-valuemin").removeAttr("aria-valuemax");
// Sys.Application.remove_load(pageLoadHandler);
}
Sys.Application.add_load(pageLoadHandler);
Hi,
For the date picker and it's family of controls (time picker, date time picker), when using bootstrap skin, lightweight rendering and RTL page, the buttons for the picker are displayed on the wrong side of the control (the right side) instead of being displayed on the left side. I know this can be fixed using some CSS but although the html controls are in order (text and then button both in a container with RTL), the button is stuck to the right side somehow
please advise