After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765370 - Can't set event's time when time format is "AM / PM"
Can't set event's time when time format is "AM / PM"
Status: RESOLVED FIXED
Product: gnome-calendar
Classification: Applications
Component: User Interface
3.20.x
Other Linux
: Normal normal
: 3.26
Assigned To: GNOME Calendar maintainers
GNOME Calendar maintainers
: 766634 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-04-21 12:21 UTC by Lim Jongrok
Modified: 2017-04-17 18:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot - no AM/PM selection (24.55 KB, image/png)
2016-05-09 12:05 UTC, d7rk
  Details
edit-dialog: set time format unconditionally (1.48 KB, patch)
2016-07-27 19:28 UTC, Ernestas Kulik
committed Details | Review
time-selector: fix AM to PM time logic (1.04 KB, patch)
2016-07-27 19:28 UTC, Ernestas Kulik
committed Details | Review

Description Lim Jongrok 2016-04-21 12:21:06 UTC
When Gnome's time format is setted "AM / PM",
(This means /org/gnome/desktop/interface/clock-format is setted as '12h')
(System Setting -> Date & Time -> Time Format : "AM / PM")

I'm not able to set event's time after 11:59 AM ,in Gnome Calendar.

 - There is no selector for "AM / PM" in time picker.
 - I cannot set time in 24h, as hour spin button only accepts between 0 ~ 11.



Workaround: Set Gnome's time format as "24-hour". After then, hour spin button accepts 0 ~ 23, and event's time can be set PM.
Comment 1 Utsob Roy 2016-05-09 04:32:08 UTC
This is also true for me.
Comment 2 d7rk 2016-05-09 12:04:05 UTC
Same problem on Manjaro (based on archlinux) with gnome-calendar 3.20.1-1.
Comment 3 d7rk 2016-05-09 12:05:10 UTC
Created attachment 327509 [details]
Screenshot - no AM/PM selection
Comment 4 Marinus Schraal 2016-05-18 22:31:19 UTC
*** Bug 766634 has been marked as a duplicate of this bug. ***
Comment 5 Sam Bull 2016-05-23 16:22:54 UTC
This is a regression. I was able to change this in an older version (probably 3.18) with an AM/PM box. This should be changed to confirmed.
Comment 6 courthicks1 2016-07-06 17:32:24 UTC
Seems there are a a handful of features missing from GNOME 3.20, I swear it got dumbed down this release. I have this problem too with Fedora 24, GNOME 3.20.2
Comment 7 Ernestas Kulik 2016-07-27 19:28:02 UTC
Created attachment 332238 [details] [review]
edit-dialog: set time format unconditionally

If GcalEditDialog.format_24h is initialized to zero, the call to
gcal_edit_dialog_set_time_format() from GcalWindow will not make
period_combo boxes visible on systems, where 12-hour clocks are used.
This commit fixes that by removing the if statement from the function.
Comment 8 Ernestas Kulik 2016-07-27 19:28:07 UTC
Created attachment 332239 [details] [review]
time-selector: fix AM to PM time logic

Currently, the hour component of the time is doubled when switching from
AM to PM, which is incorrect. This commit fixes the logic by adding 12
hours when switching to PM.
Comment 9 Ernestas Kulik 2016-07-27 19:29:36 UTC
The second patch is for a bug I found whilst fixing the reported one. I did not file a report or check if there is one already. Apologies in advance. :)
Comment 10 Georges Basile Stavracas Neto 2016-07-27 19:34:06 UTC
Review of attachment 332238 [details] [review]:

Sure.
Comment 11 Georges Basile Stavracas Neto 2016-07-27 19:34:30 UTC
Review of attachment 332239 [details] [review]:

Nice touch, thanks.
Comment 12 Georges Basile Stavracas Neto 2016-07-27 19:37:30 UTC
Thanks for your fixes!

Attachment 332238 [details] pushed as dd4142f - edit-dialog: set time format unconditionally
Attachment 332239 [details] pushed as d0143db - time-selector: fix AM to PM time logic
Comment 13 Alexander 2016-08-19 22:37:30 UTC
Is this change in 3.21.4?
Comment 14 Ernestas Kulik 2016-08-20 05:33:10 UTC
(In reply to Alexander from comment #13)
> Is this change in 3.21.4?

No.