When time zone is active, kalarm still calculates time zone difference by 1 hour. The time reached is also then not honoured except for the actual time zone: Reproducible: Always Steps to Reproduce: 1. Set time for a few minutes ahead of current time eg. 8.25am (Kalarm would notify time already past). To remedy, adjust time 1 hour ahead. The alamr times now match on the display 2. 3. Actual Results: The alarm does not sound at the displayed time. It uses the timezone time with the incorrect offset time out by 1 hour Expected Results: displayed time and machine time should perform the alarm action
Can you please clarify how to reproduce this. - when you say "set time", do you mean to set the *system* time? - what alarm should be set up to test this? - what time zone are you using?
If you can provide the information requested in comment #1, please add it.
Test case: - Set New "Audio" alarm - Select audio file - Set alarm time 5 minute 5 minutes in the future from your system time When Ok is pressed, it alerts one the time is already Expired. using Timezone Africa/Johannesburg
When you start KAlarm, is the following message displayed? Time zones are not accessible. KAlarm will use the UTC time zone. If not, please check the contents of KAlarm's configuration file ~/.kde/share/config/kalarmrc. If there is an entry "tzunavailable=false" in the "[Notification Messages]" section, quit KAlarm, delete the "tzunavailable=false" line, and then run KAlarm again. Does the time zones message appear now?
Leon, does comment #4 help solving the issue? Please add a comment.
On Comment #4: The App does not display any notices during startup. These were the only entries under the Notification Section: [Notification Messages] AskAutoStart= ConfirmAlarmDeletion=true EmailQueuedNotify=false QuitWarn= Versin 4.13.3
(In reply to Leon from comment #6) > On Comment #4: > The App does not display any notices during startup. > > These were the only entries under the Notification Section: > [Notification Messages] > AskAutoStart= > ConfirmAlarmDeletion=true > EmailQueuedNotify=false > QuitWarn= > > Versin 4.13.3 I meant the current version I am using is 4.13.3 (it is not part of the config file)
In KAlarm, go to Settings -> Configure KAlarm, and select the Time & Date tab. Which time zone is shown as selected?
If you can provide the information requested in comment #8, please add it.
To further investigate this issue, KDE developers need the information requested in comment #8. If you can provide it, or need help with finding that information, please add a comment.
Timezone = Africa/Johannesburg
Thanks for the update.
Please open a terminal window and type the following command, followed by <Enter>: timedatectl Report what is displayed in the line beginning "Time zone:".
Local time: Mon 2016-02-29 08:41:12 SAST Universal time: Mon 2016-02-29 06:41:12 UTC RTC time: Mon 2016-02-29 06:41:12 Time zone: Africa/Johannesburg (SAST, +0200) Network time on: yes NTP synchronized: yes RTC in local TZ: no Additional note: since upgrading to F22 from F20, various things stopped working... like the Akonadi service, so I am unable to test further and confirm if this condition has been resolved in F22/F23
This is due to a bug in the KDE PIM libraries (in kcalcore). See https://phabricator.kde.org/D1375.
*** Bug 360674 has been marked as a duplicate of this bug. ***
*** Bug 361115 has been marked as a duplicate of this bug. ***
Git commit 9800fca3b44300828a8b7d23ae962f01e47ac5ff by David Jarvie. Committed on 11/04/2016 at 19:35. Pushed by djarvie into branch 'Applications/16.04'. Fix timesInInterval() when parsing VTIMEZONE RRULE components KDateTime::isValid() (KF5 <= 5.21) wrongly returns invalid for an instance which is specified in ClockTime, if the date/time is invalid in LocalTime, resulting in timesInInterval() returning no values when parsing a VTIMEZONE RRULE component in ICalTimeZones. This is a workaround for backwards compatibility with KF5 <= 5.21. Differential Revision: https://phabricator.kde.org/D1375 FIXED-IN: 16.04 M +2 -1 src/recurrencerule.cpp http://commits.kde.org/kcalcore/9800fca3b44300828a8b7d23ae962f01e47ac5ff
*** Bug 362283 has been marked as a duplicate of this bug. ***
Git commit af320ed5599cb0737c0601e26126c39e64780de0 by David Jarvie. Committed on 05/05/2016 at 22:08. Pushed by djarvie into branch 'master'. Fix KDateTime::isValid() for ClockTime values Fix KDateTime::isValid() wrongly returning invalid for an instance which is specified in ClockTime, if the date/time is invalid in the local time zone. Bug was due to QDateTime::isValid() working differently in Qt4 and Qt5. REVIEW: 127629 M +16 -0 autotests/kdatetimetest.cpp M +11 -1 src/kdecore/kdatetime.cpp http://commits.kde.org/kdelibs4support/af320ed5599cb0737c0601e26126c39e64780de0