@VladikB Please fix the codestyle issues:

I have tested this item ✅ successfully with Chrome browser
It works as described.

Nice Feature, thank you!!!

Sorry to ruin the party but this cannot be accepted because it's not supported by the minimum browser compatibility for J4: https://caniuse.com/#feat=input-datetime

@dgrammatiko The problem being that a text field is not supported?

@roland-d no the problem is that you cannot rely on the fallback type of text wihout some client side validation. Also I think that there should be also a server side validation (input filter).

"Since IE and Safari don't support this input type, on these browsers it goes to input type="text""

"Since IE and Safari don't support this input type, on these browsers it goes to input type="text""

So I can then type: This sucks! and it will be valid time because there is no client side or server side validation. In other words you're proposing something that in it's current form is broken.
Great, ship it!

Basically you need this: https://github.com/Dan503/time-input-polyfill

Would be so great, if we would appreciate new contributions and find ways to make it work instead of shouting at each other and beeing such aggressive.

@coolcat-creations so, explaining that something is not acceptable in the current state is aggressive?

It's not what you say, but how you say it @dgrammatiko
"This sucks!" and "Great, ship it!" ... We are here to create a great product with each other, not to be mad ;-)

You should find everything you need to know about the time input and any issues you need to watch out for here https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time

@brianteeman Can You please check the language strings?

@wilsonge Is the added time rule OK like that?

@brianteeman Can You please check the language strings?

Do we even need language strings? Don't the browsers have their own native strings for this?

@brianteeman Can You please check the language strings?

Do we even need language strings? Don't the browsers have their own native strings for this?

I have no idea

create a time field and see what happens when validation is on

The language strings are primary for the browsers that don't support input type=time. So that if You enter a random text or a false time it won't be accepted and gives the message back.
In browsers that support time You just can't input wrong data.

Sorry if I wasnt clear.

Use a browser which supports time and copy the error messages from there to be used in the other browsers

There is something going sideways here. The language changes are not in relation to what browsers show but these are the message after the server-side validation is done. In case a validation fails, one of these messages are shown.

OK here you go and sorry for the confusion and please make sure they are the same frontend and admin

JLIB_FORM_FIELD_INVALID_MIN_TIME="The time you entered is before the minimum time."
JLIB_FORM_FIELD_INVALID_MAX_TIME="The time you entered is after the maximum time."
JLIB_FORM_FIELD_INVALID_TIME_INPUT="Invalid time format. Please use hh:mm."
JLIB_FORM_FIELD_INVALID_TIME_INPUT_SECONDS="Invalid time format. Please use hh:mm:ss"

Tested with the simple example proposed by OP

This is not very useful for language/countries where AM/PM is not used as one has to add these values in the field. One can't enter 13:30 for example, but 01:30 PM
So, not only it is restricted to some browsers but it is also restricted to people familiar with AM/PM

EDIT: If it based on system locale, then we may be in bad shape when using a different language in the browser or OS (did not test).

See: https://www.timeanddate.com/time/am-and-pm.html

Where Is the 12-Hour Format Used?

Most countries around the world today use the 24-hour system. However, the 12-hour format, including am and pm, is officially used in a number of countries, including the United States, Canada (except Québec), Australia, New Zealand, and the Philippines.

The fact that it is changed to a text field in Safari for example let's enter anything in that field. No error. No indication of the real format to use, etc.

So, not only it is restricted to some browsers but it is also restricted to people familiar with AM/PM

The browsers take the time format from the operating system locale

The fact that it is changed to a text field in Safari for example let's enter anything in that field. No error. No indication of the real format to use, etc.

Thats easily resolved by adding a pattern in the xml of the field definition. The time input wont use it but the fallback text input will

       pattern="[0-9]{2}:[0-9]{2}">

https://codepen.io/brianteeman/pen/xxKjPgz

No error. No indication of the real format to use, etc.
@infograf768 The test instructions were missing the latest change, so I updated them. Add the validate="time" and you will get error messages depending on your error.

The browsers take the time format from the operating system locale

Not so obvious. Here on Macintosh, these are my settings:

I checked my system locale here. It is

imac-2:~ mac$ defaults read NSGlobalDomain AppleLocale
en_FR

Therefore I should get a 24 h for the time field.
It simply does not.

@infograf768 Which browser are you using? I want to see what I get here.

I found the only way to get a 24h time field
I have to set up my Mac as (French first):

Which I don't like as I am used to an English Interface for more than 30 years...

Note: I use Firefox, but it is unrelated.

These are my settings, being Dutch I like it in English as well.

This is what I see in Firefox:

Lucky you... I use Sierra 12.10.6

Concerning validation. I added validate="time" in the xml for user name.
I do get a warning indeed in Safari, but it flashes so fast I can't even read it.

@infograf768 That flashing message is unrelated to this PR. The message is just added the message queue of Joomla.

However for me nothing flashes, all Joomla generated messages stay on screen until I close the message.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time

@roland-d

However for me nothing flashes, all Joomla generated messages stay on screen until I close the message.

Lucky you. I tested other messages in Safari and they do stay on screen until I close, but not this one.

@VladikB
I understand how it behaves in Firefox.
My issue here is with the locale.

@infograf768 I was testing in Firefox. Doing the same test in Safari, there the message flashes indeed. However it doesn't fully disappear:

There are more issues in Safari. When I go to the System dashboard it loads like this:

a second later it looks like this:

I would say we move the Safari rendering to another discussion as this is not related to the time field.

As for the locale issue, I don't see how we can do something about that because it is browser that acts upon the time input field. To rule anything Joomla out, what shows up if you create a plain html file with just this field? Attached is a zip file with the HTML file with just the input.

time.zip

Or test with the codepen I posted yesterday https://codepen.io/brianteeman/pen/xxKjPgz

@roland-d
Joomla is not at stake.
I still get the field with AM/PM with your html in Firefox as it really depends on my Mac settings.

Concerning Safari, I confirm your findings for some of the quickicons modules and agree it may have to be solved separately.

@brianteeman
Looks like your solution would help entering something which makes sense in the field in Safari, forcing 24h. Evidently the Label needs to be very informative, which may be confusing when the browser displays the time field as one, for example, would not be able to enter 17:00 in your proposal, but 05:00 PM

Note: When one gets the AM/PM field display in Firefox it shows like this:

It is not obvious that the last 2 -- mean entering AM or PM

The problem of all the dashes can simply be dealt with by providing a default value.

The problem of all the dashes can simply be dealt with by providing a default value.

Would not you need one when the time field is using AM/PM, one when using 24h + one when the time field is a text field? ;)

I think you only need 1 default value.

This will do as a starting point. I don't think we need the polyfill and the validation looks good. As this is a browser native field I don't think there is much we can be doing to work around the differences - even if there are issues. We can consider trying to normalise in the future i guess. But i don't see this being much different to things like when we added the number field etc way back.

@infograf768 i agree btw that before this is used in core we need to evaluate the lack of consistency. However I think allowing people to use native browser fields is a good idea