Add ability to disable Daylight Savings or Specify TimeZone on DateTimePicker
Optionally allow for the disabling of Daylight Savings time detection when using the DateTime picker, or to set the TimeZone for the picker manually.
Posted on:02 Dec 2022 16:02
The provided solution is related to mapping a DateTimeOffset value(this is C# related) to the DateTimePicker widget. The purpose of the DateTimeOffset is to define a date value based on UTC that is unrelated to any timezones. This in turn resolves the initial problem of having to deal with DST.
However, we do provide several methods that allow you to manipulate the timezone offset that is applied to the dates. You can use the kendo.timezone.apply method to override the default timezone that is set by the Date object.
// This will return the current date and time in UTC+0
// This will return the current date and time in UTC+1
// This will return the current date and time in UTC+2
// And so on
You can allow the users to manually set a timezone using the above approach.
Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers.Learn More.
Posted on:29 Nov 2017 22:18
Posted on:09 Aug 2017 06:46
Seems like the browser's datepicker applies local timezone but on postback C# doesn't process the timezone. Current advise from Telerik support is to manually calculate the offset and apply before posting the data and then handle it on response. This is tiresome for every datepicker.
Would be great if the Datepicker has an inbuilt property that we can choose to either use UTC or Local timezone. And it would convert and return the value so we won't have to code it everywhere ourselves.
Posted on:21 Dec 2015 16:05
In addition to adding a TimeZone config property to kendoDateTimePicker, please add this to kendoTimPicker as well. I am dealing with this right now, and it appears that the code for these controls uses whatever the user's operating system is set to, which is not always what the application needs. We have TimeZone on the scheduler, so why not on these two as well?