having 12h format is quite inconveinent when adding long enough event to cross 12pm timestamp. or at least don’t change AM/PM in opposite field (starts/ends) when setting up time cause i have to adjust timestamps several times back and forth
We are following the machine locale/region settings when it comes to using 12h or 24h time format. Perhaps I’m missing something though, can you post some screenshots of what you describe?
didn’t realize i had 12h format system wide, thanks!
the issue i described occurs though if let’s say i want to create appointment from 4AM to 1PM. when i start typing ‘1’ in Ends field, it automatically sets ‘1’ in Starts, which i have to edit again after i set PM in Ends:
- create new calendar event
- set Starts: 4:00 AM.
- set Ends: start typing 1. this affects Starts field so i have to edit it again
There’s unfortunately not much we can do here because otherwise we would let you create times that are not possible, i.e. from 4:00 AM to 1:00 AM on the same day…
Regarding the 24h clock setting, we’ll have a look if that’s honoured or communicated to Agenda.
a simple validation ‘starts’ <earlier> than ‘ends’ will suffice, not sure what you mean…
What I mean is that if you have already 4:00 AM in “starts”, and start typing a “1” in ends, the picker will now be in an inconsistent state (1:00 AM, which starts earlier than the start time), which means we somehow have to fix it and change one of either start or end date. We’ll see if it is possible to change it to 1:00 PM automatically to prevent it from having to change the start date, but not sure whether that’s possible.
but at this point i haven’t finished my input, so this feels kinda annoying that the app interrupts me and forcibly suggests wrong values.
input validation should happen on user’s submit, that’s my point
For this type of picker the system assumes text entry as commits, see for example the calendar app.
great example, thank you. it won’t change hour value from previous input, it’ll change am/pm accordingly, you should try our 4am - 1pm example for yourself (desktop calendar app)
Yes, that’s what I mean above:
We’ll see if it is possible to change it to 1:00 PM automatically to prevent it from having to change the start date, but not sure whether that’s possible.
1 Like
optional 24h format will definitely help 
for context: I have my system set up to use 24 hour format and I get 24 hour format in agenda. but I still have an issue here
here’s a simple way to reproduce what I consider to be a bug (on macOS):
- create a new event from a note
- enter the start time as 23:00
- tab to the next field
- enter “03” in the end time field
what happens:
- as soon as I type the “3”, the start time is switch to “03:00”
- if I tab back and change the start time to “23” again, it swaps the end time to “23”
end result: there’s no way for me to enter in an event that starts one day and finishes on the next day, i.e., any event that spans midnight
what I expect to happen:
- when I enter “03”, the app realizes that the most logical explanation for the input so far is that the “03” refers to the NEXT 03 after the 23 hour, and switches the date input so that the date is listed next to the time. with the current date being set for the start time, and the date of tomorrow being set for the end time. the start time is left at 23:00, and I am allowed to type “03:00” for the end time
the end result is an event that spans midnight
the way I describe this is the exact functionality of Apple’s calendar app. to reproduce the desired behavior, create a new event at, say, 10pm on the current day in Calendar app. then, click in and edit the times. set the end time to “03” and you’ll see that the app increments the date of the end time so that the event spans midnight
at the moment, this bug is really frustrating. I end up having to create a short event that ends at say “23:59” (because you can’t pick “00:0”, because if you do the same thing will happen as before: the start time is auto-set to “00:00” which totally breaks what you’re trying to do) open calendar app and set the end time correctly, which is a broken workflow imo
Sounds indeed the same solution as we discussed above, I’ll give it a go
1 Like
thank you!
1 Like