Use 24 hour time format instead of AM/PM
We are more familiar with 24HH format. Thit feature would help europe customers.
It would be great to have ability to select timezone in UI at user or site settings.
-
Amit T commented
It is really confusing when we use AM/PM format.
-
Pieter Jamaer commented
For a product like Octopus, it is really unprofessional to have a 24h clock possibility. Can this be added please?
-
Arve Systad commented
It's insane that this is not possible to change in 2021. The 12h clock is bizarre for anyone who hasn't learned it from childhood (heck, it's bizarre even then). I just missed a midnight deploy because of it, and it looks like I'm not the first. A few hours spent on this is guaranteed to save many, many more all over the world - not to say the risk it'll mitigate for many users.
-
Rik Crompton commented
This is a good idea. I've just deployed in the middle of the working day instead of overnight because the AM/PM is indistinct. 24 hour format instantly rules out this possiblility (for those who choose to use it).
I'm all for designing out bugs in systems, and this would appear to be an easy one to implement that would prevent an easy mistake. -
Roman commented
Specifying midnight always requires extra concentration and careful double-checking. You probably don't realise how unnatural this is for someone who didn't grow up in a 12-hour time country. Please implement this!
-
B Richardson commented
I find the time field for scheduling deployments a tad tedious. Changing one component of the time field automatically adjusts a different component of the time field, and can result in going round and round in a frustrating manner to quite simply set a date and time. If this field could be 24 hour clock, I could set this in a straightforward manner which would ultimately not lead me to making mistakes of scheduling something in AM instead of PM and vice versa; which has happened!
-
Stian commented
(y)
-
Simon Taubert commented
Get to it please!
-
DR commented
Quite frankly, this is embarrasing. That you are pushing an automation tool that does not support ISO-8601 (you know, yyyy-MM-dd HH:mm:ss) is amusing. Unfortunately we have to use it and that is where the amusement stops.
-
B Au commented
Yep, something my team keep asking for. If you must have the AM/PM then have a setting to allow us the option to use 24 hour format.
-
John commented
Yes pleeease!!!
-
Magnus Ahl commented
Yes, for Gods sake! It's time for som internationalization. At a _minimum_ use the servers localized time zone and output format in the GUI. Then a local installation will be okay, even though an international organization llike my own will struggle.
-
Adam Connelly commented
I would really like this - I'm used to working in 24 hour, so I find it pretty confusing using AM/PM since everything else on my computer is all setup to use 24 hour. Also, the UI is more awkward to use because you have to change three boxes instead of two, and you have this weird situation where the order of the boxes on the screen from right to left isn't really the logical order you would want to enter them.
-
mark commented
Three times now In have deployed 12 hours early or late.
-
Rick van Lieshout commented
We also have very small deploy windows. AM/PM is a disaster waiting to happen.
-
Hans Melin commented
I scheduled a deploy yesterday to start 7 this morning, but nothing was deployed since I accidentally set it to PM instead of AM... So please, add a setting to use 24 hour clock.