Bug: calcite-input-time-picker - when entering time without ':' into input box

[AdelheidF]

Actual Behavior

When editing the time value directly inside the input box then it works well if I stick to the format and leave the ‘:’ alone. If I remove a ‘:’ though things don’t work anymore. It would be nice if it added the ‘:’ automatically back in. This is especially useful if I started with an empty input box.

Expected Behavior

it adds ':' ever second number

Reproduction Steps or Sample

<calcite-input-time-picker></calcite-input-time-picker>

1. Type 123456 into the input box
2. Unfocus the input
3. Result: the value goes away instead of being formatted as a valid 12:34:56 time value.

Relevant Info

Version: @esri/calcite-components@<version>

• CDN
• NPM package

[eriklharper]

Not sure if this is a bug more so than it might be a feature request because the entered value will format correctly when the input box loses focus.

Is the requirement that the colon should be added and the value format updated on every keypress in the input box?

I avoided implementing it this way because I found the UX jarring while I was typing to see characters I hadn't typed being put in there. I opted to just let the user type the value and then worry about formatting the resulting value after they blurred the input, which commits the value. When the value isn't a valid time value, it reverts back to the previous valid value (which also includes no value).

@jcfranco thoughts?

[AdelheidF]

because the entered value will format correctly when the input box loses focus.

This is not what I'm seeing. If I type 123456 or 120000 and click outside the input box the input box clears out. (next.245)

If I type in : it's fine.

Maybe it's OK to require users to enter those :.

[jcfranco]

The above does look like a bug.

I agree w/ @eriklharper's comment about formatting while you type jarring. If we can fix the above without requiring : as users type, it'd make it easier to use.

[eriklharper]

I see that now. As long as the number can convert to a valid time value, I think it should add the colons in on blur. I'll update it to do just that.

[eriklharper]

@AdelheidF : I discussed this with @jcfranco and we came up with the idea to create a new calcite-input-time component that will replace the current input box inside calcite-input-time-picker which will be modeled after the native browser implementations like this one from Chrome:

The behavior will essentially change from being a free-form text field, to established input fields that act as a mask for entering time values.

[jcfranco]

if we can fix the above without requiring : as users type, it'd make it easier to use.

For posterity, we backed off from option this because of the many ambiguous values it introduces.

[eriklharper]

These ones I labeled "vague" are the values that can be interpreted multiple ways and would induce a lot of confusion if we tried to support them because some people would expect for instance 1111 to be 01:01:11 and another person might expect it to be 11:01:01

[AdelheidF]

Is there already an issue for this calcite-input-time component? I can't find it to link here.

[AdelheidF]

Issue created for calcite-input-time #2709