When typing 130 the TimePicker yields 3:00

Progress® Telerik® UI for Blazor Feedback Portal

Create an account Log In

Back to Feed

Request a Feature Report a Bug

Declined

Last Updated: 23 Jan 2024 18:13 by ADMIN

Joe

Created on: 22 Dec 2023 14:26

Category: TimePicker

Type: Bug Report

When typing 130 the TimePicker yields 3:00

The up/down arrows going up/down works great, but when you are typing the time in directly, it has issues. It seems that if I type the time for hours 2-12, it works exactly as I'd expect. If I type 215, it yields 2:15, if I type 1130, it yields 11:30. But if I type 130, it yields 3:00.

4 comments

ADMIN

Nadezhda Tacheva

Posted on: 23 Jan 2024 18:13

Hello Joe,

Thank you for your input! Please see my comments on the listed points as follows:

1) If you type anything in the 1pm hour, it doesn’t know what to do and yields the wrong results. 1:30 yields 3 AM for example.

Details on the current behavior you may find in my previous response.

As for your suggestion for a free-form, indeed such a scenario can be covered by this functionality. You are correct that we have a feature request for that: Remove the DateInput mask and type free text. I see you already voted for it.

===

2) There is some mismatch of using the picker vs typing, in which one causes the date portion to revert to today’s date but the other keeps it the same. So you have to use a valuechanged function to revert back.

It sounds to me like you are referring to this bug: Writing the time with the keyboard changes the date portion to the current date.

I see that a member of your team already voted for it. You may also follow it to get status updates. A workaround for the time being is to indeed handle ValueChanged to manage the date value.

===

3) There is some kind of delay that I thought was related to the timepicker, but it seems to occur with many components in general.

Based on the description, this behavior is most likely related to the default debounce delay that the inputs have - its value is 150ms. Setting that to 0, you should not experience a delay between typing and updating of the value.

In case you are hitting a different behavior, please open a dedicated ticket and send a runnable reproduction, so we can revise it.

===

4) The am/pm section shows “aa”.

This point also targets a completely different behavior than the one discussed in this thread. So far, we haven't received a report for such an issue.

May I ask you to again open a dedicated report and either include a reproduction or list the exact steps that we need to perform in order to reproduce this behavior on any of our demo pages? Once we have that, we can validate whether it is a matter of component configuration or a bug.

Thank you in advance!

Regards,
Nadezhda Tacheva
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!

Joe

Posted on: 16 Jan 2024 20:55

Hello again,

There have been a few things that have gotten complaints with the Time Picker, most that I’ve already relayed.

1) If you type anything in the 1pm hour, it doesn’t know what to do and yields the wrong results. 1:30 yields 3 AM for example.

a. My suggestion was to make it free-form and you’d convert after (which sounds like you have an open feature request for still).

b. Otherwise, my suggestion was to put in some logic based on the configuration of the component and in cases where only one option would be valid, assume the valid option (instead of assuming they are making a typo). That is going to yield a nicer user experience. Examples:
- 13 is never a valid hour if you’re using am/pm, so you should just assume they are entering 130. The same goes for anything above 12.
- We are using 15 min increments, so in most cases there is only one possibility and you can decide by the third character entered what it’s destined to be and shift appropriately. Ex: 115 = 1:15, 130 = 1:30, 145 = 1:45, 111 = 11:15, 113 = 1130, etc. There are still some where you won’t know the intention until they are finished typing, they type am/pm, or hit tab/enter. It may not be possible to make it completely elegant without free-form text.
- I agree if you can make 01 always work for 1, then that does help with this particular item, but intuitively people may not think to do that initially. Still helpful though.

2) There is some mismatch of using the picker vs typing, in which one cases the date portion to revert to today’s date but the other keeps it the same. So you have to use a valuechanged function to revert back.

3) There is some kind of delay that I thought was related to the timepicker, but it seems to occur with many components in general. If you are typing and hit tab or enter too quickly after typing, the change event will not see the last character you typed. I got multiple reports of this with the time picker and numeric text box where the result was wrong. You do have to tab or enter quickly, however, that is what users are going to do. They get used to a process and do it fast.
- The only way I was able to resolve this was by calling a JS function to grab the value from the field at the time of saving and override. Pretty wonky.

4) This is harder to reproduce, but there will be cases where the am/pm section shows “aa”. Once it reaches that point the control doesn’t function. Whether I type a, p, or use up/down arrows, it never resets back to AM or PM. I have to actually go into the time picker, select PM, click set. Go back in, click AM and click set.

I think most of your components are great, but this one has a lot of issues. Some that are deal-breakers. Especially in a process where people are logging time throughout the day. It has to work really well. For this reason, we had decide din the short term to write something fully custom to resolve the issue. If you later roll out the free-form text option, depending on how that works, maybe we will switch back to using the timepicker.

Thanks,

Joe

Posted on: 16 Jan 2024 20:52

Hello again,

There have been a few things that have gotten complaints with the Time Picker, most that I’ve already relayed.

If you type anything in the 1pm hour, it doesn’t know what to do and yields the wrong results. 1:30 yields 3 AM for example.

My suggestion was to make it free-form and you’d convert after (which sounds like you have an open feature request for still).
Otherwise, my suggestion was to put in some logic based on the configuration of the component and in cases where only one option would be valid, assume the valid option (instead of assuming they are making a typo). That is going to yield a nicer user experience. Examples:

13 is never a valid hour if you’re using am/pm, so you should just assume they are entering 130. The same goes for anything above 12.
We are using 15 min increments, so in most cases there is only one possibility and you can decide by the third character entered what it’s destined to be and shift appropriately. Ex: 115 = 1:15, 130 = 1:30, 145 = 1:45, 111 = 11:15, 113 = 1130, etc. There are still some where you won’t know the intention until they are finished typing, they type am/pm, or hit tab/enter. It may not be possible to make it completely elegant without free-form text.
I agree if you can make 01 always work for 1, then that does help with this particular item, but intuitively people may not think to do that initially. Still helpful though.
There is some mismatch of using the picker vs typing, in which one cases the date portion to revert to today’s date but the other keeps it the same. So you have to use a valuechanged function to revert back.

There is some kind of delay that I thought was related to the timepicker, but it seems to occur with many components in general. If you are typing and hit tab or enter too quickly after typing, the change event will not see the last character you typed. I got multiple reports of this with the time picker and numeric text box where the result was wrong. You do have to tab or enter quickly, however, that is what users are going to do. They get used to a process and do it fast.

The only way I was able to resolve this was by calling a JS function to grab the value from the field at the time of saving and override. Pretty wonky.

This is harder to reproduce, but there will be cases where the am/pm section shows “aa”. Once it reaches that point the control doesn’t function. Whether I type a, p, or use up/down arrows, it never resets back to AM or PM. I have to actually go into the time picker, select PM, click set. Go back in, click AM and click set.

I think most of your components are great, but this one has a lot of issues. Some that are deal-breakers. Especially in a process where people are logging time throughout the day. It has to work really well. For this reason, we had decide din the short term to write something fully custom to resolve the issue. If you later roll out the free-form text option, depending on how that works, maybe we will switch back to using the timepicker.

Thanks,

ADMIN

Nadezhda Tacheva

Posted on: 15 Jan 2024 15:51

Hi Joe,

We have re-evaluated this report with the development team. As a result, we have concluded it is not related to a bug and I have updated the status of the item. Let me provide more details on the behavior.

When you type "1" in the hour segment, the focus should remain there as this is not a confirmed complete hour value. In other words, the user may want to type another number after the "1" to get the hour "12" for example.

The TimePicker cannot know whether the user wants to keep the hour just "1" nor it can auto-switch to the minutes if the second typed number is invalid. For example, if one is using a "hh" format (a 12-hour clock), the only valid numbers that can be typed after "1" are "1" or "2". Thus, if you type "3" after "1", the clock rolls back and gets just the "3".

Considering this, when typing "130" the TimePicker is not expected to yield 13:00. However, one should be able to type "01" and this should move the focus to the minutes. This is the approach that you may use to produce the desired value.

Note:

Depending on the format that you use, you may hit a different problem that I identified while testing: https://feedback.telerik.com/blazor/1637366. You may vote for that item if you want to use this format.

My suggestion is to use format "HH:mm" or "h:mm" until this is fixed. Using these formats and typing "0130" you will get a "(0)1:30" value.

Regards,
Nadezhda Tacheva
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!