There was a typo in function name, which was only setting
the upper bound for 24 hour time format. As the default
lower bound is 0, no issue was known so far.
But in cases like the user switched from 12 hour to 24 hour
format there is a chance for some issues to appear as the lower
bound of 12 Hour format is 1, and it won't be reset to 0 when
the user has switched to 24 hour format.
https://bugzilla.gnome.org/show_bug.cgi?id=781448
By using finalize and dispose methods and calling the proper free
methods calls.
8,806 (64 direct, 8,742 indirect) bytes in 2 blocks are definitely lost in loss record 18,367 of 18,534
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x9A26A95: g_slice_alloc0 (gslice.c:1051)
by 0x99E8DC4: g_date_time_alloc (gdatetime.c:428)
by 0x99E8FA3: g_date_time_from_instant (gdatetime.c:524)
by 0x99E933F: g_date_time_new_from_timeval (gdatetime.c:647)
by 0x99E93A5: g_date_time_new_now (gdatetime.c:705)
by 0x99E93C4: g_date_time_new_now_local (gdatetime.c:728)
by 0x445BED: gcal_time_selector_init (gcal-time-selector.c:249)
by 0x9584B32: g_type_create_instance (gtype.c:1866)
by 0x956BED0: g_object_new_internal (gobject.c:1783)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
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.
https://bugzilla.gnome.org/show_bug.cgi?id=765370
The edit dialog time picker didnt take into account GNOME's hour format.
The edit dialog time picker didnt take into account GNOME's hour format because the desktop settings clock-format from gcal-window was not passed to gcal-edit-dialog.
Now the data is passed through the function gcal_edit_dialog_time_format and everything works as required.
https://bugzilla.gnome.org/show_bug.cgi?id=703321
