Timepicker always displays midnight on blur

[Lee]

I am having an issue where when I select a different time from the timepicker it is reverting back to zero. I have created a dojo with 2 timepickers. Both are initiated in a loop and stored in an object with the key being the id of the input. My issue is that if I set dateInput to true the time reverts back to midnight on blur. When I console.log the value though it is the value I picked. This is only an issue on the timepicker that has the min and max options set. I need the user to be able to input a time using the datepicker formatting and only choose from select times. 

Dojo:

https://dojo.telerik.com/@dojolee/UQuBiNoV

 

[Georgi Denchev]

Hi, Lee,

Thank you for the provided Dojo.

You need to update the min/max configurations of the dateInput as well:

  timePickers["reviewScheduledStartTime"]._dateInput.setOptions({
      	min: new Date(2000, 0, 1, 8, 0, 0),
        max: new Date(2000, 0, 1, 23, 0, 0)
    });

Modified Dojo:

https://dojo.telerik.com/@gdenchev/EBOyaQeD 

Let me know if you have any questions.

Best Regards,
Georgi Denchev
Progress Telerik

[Alexa]

Hi Georgi,

Does Kendo consider properties named with a leading underscore to be "private"? Or in other words, are they not intended to be used directly? My concern with the solution proposed above is on future updates _dateInput will not be available or will work differently, but the changelog may not mention changes to "internal" properties.

I looked in the Timepicker docs and API but didn't see anything about _dateInput. I just found that DateInput is a widget itself and can be integrated into timepickers via the dateInput (boolean) option. Please let me know if I did miss some documentation. 

I ran into the same problem and will use the proposed solution for now; I just ask because I have run into some hard-to-track bugs using internal properties from other libraries when they were updated. :) 

Thanks,

-Alexa

[Lee]

I agree with Alexa. This is working for me right now but seems very sketchy and is a pain to have to do everywhere in the code. I'm running into a similar issue with the placeholder text "mm/dd/yyyy" or "hh:mm" in date and time pickers where I have to use the _dateInput.setOptions. 

[Georgi Denchev]

Hi, Alexa and Lee,

Yes, properties that start with _ are deemed as private. The DatePickers are a bit more unique as they integrate a secondary component when a particular setting is enabled.

At the moment, the only properties of the dateinput that can be modified through a parent component's configuration are the messages:

https://docs.telerik.com/kendo-ui/api/javascript/ui/timepicker/configuration/messages.dateinput 

Nevertheless, allowing other DateInput options to be set through the parent widget seems like a valid idea to me. I'd recommend opening a Feature Request in our portal as this helps us keep track of the demand for particular features.

Best Regards,

Georgi

[Lee]

With the recent Kendo Update, this seems to be causing an issue again. The actual date seems to matter for the ._dateInput part of this. What worked before in the answer submitted by Georgi no longer works. Instead I'm having to change the year to 2100 and I have to include setOptions in more places than before. The only change was that I upgraded from Kendo UI 2022 to 2024.3

timePickers["reviewScheduledStartTime"]._dateInput.setOptions({
      	min: new Date(2000, 0, 1, 8, 0, 0),
        max: new Date(2100, 0, 1, 23, 0, 0)
    });

[Georgi Denchev]

Hi, Lee,

I tested the Dojo from my previous reply with the latest Kendo version:

https://dojo.telerik.com/kizNIdVQ 

However, the suggestion seems to still be working.

In fact, you don't even need to call `setOptions` for  the dateInput now:

https://dojo.telerik.com/VdQuREsA 

Best Regards,

Georgi

[Lee]

I think the issue comes in when you populate the time picker with a value that has a date outside of the min / max range, even though the time part falls within the accepted range. In my example, the person is trying to edit their previously scheduled a meeting time. Because the database holds something like 2024-09-30T10:00:00, and it is already past 9/30/24, it causes problems, even though the date part is not important to the time picker. Here is an update of your Dojo showing what I mean: 
https://dojo.telerik.com/dEMcZbXs

Notice that when you click in the date box, and then click back out of it, the time changes to 11:00 PM. If you click in and out of the box a second time, "Changed" is logged with 11:00 PM. 

[Georgi Denchev]

Hi, Lee,

I'll try to break the answer in a few parts because it's a bit difficult to follow which behavior is being reported as problem at the moment.

If you wish to stop the automatic adjustment of the time, you can pass `false` to the autoAdjust property.

When saving values in your storage/database, you could force the "date" portion to always be the same and only keep the time.

Finally, the change event part is a bit tricky. The change event is purposefully made to not trigger on programmatic changes(e.g. when you call the value() method). The auto adjustment does just that, it updates the value when you click in and outside the input, however it does not throw a change event.

The second time you focus and blur the input is when the picker detects there is a change and this change was not caused by an internal method, but rather a user action. Which in turn triggers the change event.

Best Regards,

Georgi

[Lee]

The problem is that this is a time picker so dates should not matter. If the user selects something like 5AM for their time, and the valid times are 8am-5pm, that should fail regardless of the date. The opposite is also true, if they choose 9am, it shouldn't matter what the date is. It seems like date does matter though because when a min and max are set, even though it says it ignores the date part, it clearly doesn't. The most important issue to me is that the user should be able to click in the box, click back out of the box, and the value doesn't change simply because the timepicker, when initiated, used an arbitrary date that was not supposed to be acknowledged anyway. 

[Georgi Denchev]

Hi, Lee,

The current implementation relies on the full JS Date object which is why the year/month/day also affect the value.

Theoretically speaking, it should be possible to handle this internally, but for the time being the only way is to manually format/refactor the dates before you save them/after you retrieve them from the storage.

Again, this sounds like a good idea to me, so just as I said in my initial reply, I would recommend that you open a Feature Request for it. Tracking the demand of a particular enhancement/feature is one of the main things we look into when deciding what goes in the roadmaps.

Best Regards,

Georgi