Open Dogo69Dog opened 2 months ago
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
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?
Gotcha about the deadlines, no pressure as its not something big. I do have some things to add about your ivestigation
2.Expected start and end on top bar, and actual start, and time now \
Those are all i could find. Thanks for your response
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. Is it worse of to have the same interface (editor) showing formatting in different ways? In which case, should we say that the editor interface will stick to 24hour formatting, at least for now?
I actually wonder if this was the reason to leave this in 24hour to begin with. What do you think?
As for your comments
- On the web, and on the operator view it also displays some things in 24h format
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?