-
-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time Now Not In 12H Format #1191
Comments
Hi @Dogo69Dog , thank you for this. The production views historically always had 24hour formatted times, for no other reason than that no one ever requested otherwise I have made a task for us and we will look into adding this to a near release |
Thanks for making it a task. When do we think it iwll be implemented? I have a event coming up in 1 month (October 15) and i would like this feature so its easier to calculate things |
Hi @Dogo69Dog, I am cautious of signing up for deadlines, but I dont see a reason why we should be able to get this in the next release. From my brief investigation, a large part of the work is identifying in the interface, clocks that should be formatted. As I can see all signage views already display the 12-24 hour format correctly, so the missing work is
Can you maybe help sanity check here? |
Thank you @Dogo69Dog I was starting to look into this today and realised that we also have timers in 24hours in the event blocks in the editor At the moment, it is not viable to change this to display AM/PM formatting, which makes me wonder. I actually wonder if this was the reason to leave this in 24hour to begin with. What do you think? As for your comments
As far as I can see, this seems correct to me, Elapsed time and Running timer are durations and cannot be formatted in AM/PM, ie: it makes no sense to say that its been 3:10PM since we have started |
Hmm, maybe we can add a setting to toggle between the block editor being in 24h or 12h mode? I do see why you would keep it in 24h mode but I think if the setting is 12h mode then most things should be in 12h to keep it consistent. The operator view on 24h makes sense |
Hi @lukestein and @tcconway, could I have your opinion here? It is not viable for us to move the input in the blocks to display AM / PM, although this could happen in future. The question is: if we cant change it, does it make sense to change the remaining time fields in the editor view, or would we rather maintain consistency to have the same interface displaying the same formatting? ie: editor view is in 24 hour clock |
I think it does, makes it easier for people who are used to 12h format. Once the operator is more familiar with 24h format they can have the operator view more consistent all across by switching back to 24 format. This way it helps both parties (12h people and 24h) |
Love this discussion. My take:
|
My instinct agrees with @tcconway here. If the edit fields only operate in 24h, I think it's cleaner to draw the line around operator/editor vs. viewer rather than have what may look to users like a bug (a setting for 12h that somehow doesn't seem to "work" everywhere expected). Just also reminding everyone that 12h also works for quick entry and spreadsheet import, even if it's not what displays ;) |
is there a way to have the top bar be in 12h format instead of 24h?
The text was updated successfully, but these errors were encountered: