Skip to content
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

Open
Dogo69Dog opened this issue Aug 26, 2024 · 10 comments
Open

Time Now Not In 12H Format #1191

Dogo69Dog opened this issue Aug 26, 2024 · 10 comments
Labels
improvement Improvement on existing feature

Comments

@Dogo69Dog
Copy link

is there a way to have the top bar be in 12h format instead of 24h?

Screenshot 2024-08-25 at 11 57 29 PM
Screenshot 2024-08-25 at 11 57 52 PM

@cpvalente
Copy link
Owner

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

@cpvalente cpvalente added the improvement Improvement on existing feature label Aug 27, 2024
@Dogo69Dog
Copy link
Author

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

@cpvalente
Copy link
Owner

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

  • Editor overview
  • Cuesheet
  • Operator

Can you maybe help sanity check here?

@Dogo69Dog
Copy link
Author

Gotcha about the deadlines, no pressure as its not something big. I do have some things to add about your ivestigation

  1. Expected start and end
    Screenshot 2024-09-18 at 9 50 16 PM

2.Expected start and end on top bar, and actual start, and time now
Screenshot 2024-09-18 at 9 50 36 PM\

  1. On the web, and on the operator view it also displays some things in 24h format
    Screenshot 2024-09-18 at 9 52 16 PM

Those are all i could find. Thanks for your response

@cpvalente
Copy link
Owner

cpvalente commented Sep 21, 2024

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

Screenshot 2024-09-21 at 12 16 41

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

  1. 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

@Dogo69Dog
Copy link
Author

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

@cpvalente
Copy link
Owner

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

@Dogo69Dog
Copy link
Author

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)

@tcconway
Copy link

Love this discussion.

My take:

  • operator views should always be 24h. It just makes the most sense when you are tracking time.
  • viewer views can be toggled. Maybe have the setting language reflect that: “Toggle View times. Switch between displaying a 12:00 AM and 24:00. Note that this only affects end-user interfaces and not operator interfaces.”

@lukestein
Copy link
Collaborator

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Improvement on existing feature
Projects
None yet
Development

No branches or pull requests

4 participants