After converting an all-day event to time-based 12-hours format, setting time to PM and lowering the hour with the `-` spinbutton, end date shifts forward to next day's midnight
This is a successor to #91 (closed) and #336 (closed). It is in fact @mcatanzaro's #336 (closed), but investigated and clarified with only what remains of the issue.
This has been tested with version 45.1 and nightly, and has affected every version since at least 2018 to 2023, and possibly older.
Most of the other peripheral issues that were seen in issue #91 (closed) (which would affect 24-hours format users) have been fixed, a very long time ago.
To reproduce
-
In GNOME Settings > "Date & Time", set "Time Format" to "AM / PM" instead of "24-hour".
-
In GNOME Calendar, create a new event with the advanced event editor dialog
-
Toggle the "All day" switch to convert it to a time-based event;
Notice that by default, the start time is set to "12 AM" (i.e.: midnight) for both start time and end time. -
Click the "AM" combobox on the start time widget, and set it to "PM";
Notice that the start time's number remained at "12" (but now PM, so 12:00 in 24-hours format), but the end time has now shifted to "01" PM (a.k.a. 13:00 in 24-hours format), which makes sense -
Click the
-
spinbutton widget on the start time to lower the number from "12" PM (i.e. 12h00) to "11" PM (which is actually 23h00, because ha ha screw you that's why ...)
Actual results
As a result, the 12h PM --> 11h PM shift messes everything up, because the start date always remains today (as it should...), but since you technically moved the start time one day back in time (because you went from 12:00/noon to 23:00), you can now observe that the end date gets bumped 1 day into the future (because you use 12-hours time, and therefore GNOME Calendar assumes you are masochistic), with the end time being set to... 12:00 AM (a.k.a. midnight, a.k.a. 00h00, a.k.a. 24:00) on the next day.
It is slightly less worse than issue #336 (closed) though, because nowadays adjusting the end time doesn't shift the start time/date, so it's still possible for the user to correct this.
Further observations / alternate reproduction with 24-hour mode
If your system is set to 24h time instead of AM/PM, you can still sort-of reproduce the issue from a theoretical standpoint and see what GNOME Calendar is doing behind the scenes, by entering "24" (or anything above 23 as the start time's hour)... in that case, GNOME Calendar will reset the start time to 23:xx (no matter what number you enter that is above 24) but that is theoretical, because it makes makes no sense practically (24h/military-hour users don't use numbers above 23h59).
The only actual bug I could find with 24-hour format is #1121.
Workarounds for users
Don't use AM/PM if you don't like pain.
Friends don't let friends use 12h format.
Possible technical solutions
Fixing #393 might incidentally fix / dodge this issue here too (or not)...
Otherwise, I'm not sure how to fix this properly, in terms of heuristics and UI logic, other than disabling "smart" time/date shifting entirely when using the 12-hour format; AM/PM is a nightmare, but this issue doesn't really affect 24-hour format users.