12 vs 24 hour clock consistency

[fhteagle]

Much of the UI uses 24 hour clock (i.e. 7PM is 19:00), but some places use a 12 hour clock, such as the schedule input boxes.

Best of all possible worlds is to let the user pick 12 or 24 hour time format based on what they are comfortable with and use that everywhere in the UI (could this also trigger a change in format for the physical display?!?). Second best would be using consistently either the 12 or 24 hour clock everywhere in the GUI, and no option to change it. I personally prefer 24 hour clock, but I know many people, especially in North America, who are not comfortable with this.

If the answer is to allow or standardize on 12 hour clock, then the time input box on the schedule tab should be widened to show the AM/PM marker:

Thoughts?

[jeremypoulter]

This is also a problem for the LCD, could do with a config settings for 12/24 hour?

[KipK]

The native time picker is handled by your OS settings , It displays 24h time format here. But I can force AM/PM time on displayed time depending of the region. I already do something similar here, as it display DD/MM/YY or MM/DD/YY depending of the region.

[KipK]

Can you confirm me the time input box now has correct size to display am/pm ?

[fhteagle]

Scheduled time input box is now wide enough to support AM/PM display, yes.

Can you let the browser use its own time format config to display "Next Event" and the schedule time table values as 12h or 24h format? That would at least solve the GUI consistency problem, but not the physical display question.

[KipK]

now all time input use system configured time format, so this should be unified on the UI ( but the current/next event for now as they display time format used by api for now) , can you confirm ?

[fhteagle]

All inputs appear to be in browser controlled 12 / 24h in commit cccdb8d4934974b0c49597cc4345eb0cd4f15607 , yes. Some GUI display only elements are still forced to 24h time as you said.

[KipK]

this should be adressed in last commit.