Upcoming recurring alarms on wrong day

[Alan Pope 🍺🐧🐱 🦄]

Open clock
Set alarm, make it occur every working day - and today is Tuesday.
Save alarm.
Pull down indicator, observe that "next" alarm is shown as "Mon" not "Wed" which is tomorrow.

Expectation would be that the indicator shows the next alarm, not the one 4 alarms away.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: indicator-datetime 13.10.0+14.04.20140408-0ubuntu1
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.14.1-0ubuntu2
Architecture: armhf
Date: Tue Apr 15 18:35:01 2014
InstallationDate: Installed on 2014-04-15 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS - armhf (20140415.1)
SourcePackage: indicator-datetime
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Charles Kerr (charlesk)]

I'm able to reproduce this issue on r297, right after a full reflash. Just create a morning alarm for M-F, and even though today is Tuesday, indicator-datetime shows the upcoming time as Monday.

[Charles Kerr (charlesk)]

Looks like this might be a clock-app bug rather than an indicator-datetime one. Here's what gets saved in EDS' backend. Note that today is April 15 but the alarm's start date is stored as April 21 ("DTSTART:20140421T060000")

phablet@ubuntu-phablet:~/.local/share/evolution/tasks/1397587814.2867.0@ubuntu-phablet$ date
Tue Apr 15 19:54:29 UTC 2014
phablet@ubuntu-phablet:~/.local/share/evolution/tasks/1397587814.2867.0@ubuntu-phablet$ cat tasks.ics
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
X-EVOLUTION-DATA-REVISION:2014-04-15T18:52:29.729672Z(2)
BEGIN:VTODO
UID:20140415T185226Z-2867-32011-2021-1@ubuntu-phablet
DTSTAMP:20140415T185226Z
DTSTART:20140421T060000
DUE:20140421T060000
RRULE;X-EVOLUTION-ENDDATE=19700101T000000Z:FREQ=WEEKLY;COUNT=-1;
 BYDAY=MO,TU,WE,TH,FR
SUMMARY:Alarm
CREATED:20140415T185226Z
LAST-MODIFIED:20140415T185226Z
BEGIN:VALARM
X-EVOLUTION-ALARM-UID:20140415T185226Z-2867-32011-2021-2@ubuntu-phablet
ACTION:AUDIO
ATTACH://///w==
END:VALARM
BEGIN:VALARM
X-EVOLUTION-ALARM-UID:20140415T185226Z-2867-32011-2021-3@ubuntu-phablet
ACTION:DISPLAY
ATTACH://///wAAAAoAQQBsAGEAcgBt
END:VALARM
END:VTODO
END:VCALENDAR

[Charles Kerr (charlesk)]

This value is being set in qtorganizer5-eds by QOrganizerEDSEngine::parseTodoStartTime(), which gets the value from a
call to a QOrganizerTodoTime.startDateTime().

Looks like the QOrganizerTodo gets set in ubuntu-ui-toolkit/modules/Ubuntu/Components/plugin/adapters/alarmsadapter_organizer.cpp in AlarmsAdapter::organizerEventFromAlarmData(), which sets the start date and due date from the same value, "alarm.date", where alarm is an AlarmData and date a simple property that gets set in UCAlarm::setDate(date)'s call to d->rawData->date = date. So at that point I think we're back to the qml.

Oddly, ubuntu-clock-app/alarm/AddAlarmPage.qml's function to save a new alarm, saveNewAlarm(), creates a new Date object, updates its time fields based on the user's choices, and appears to leave the date fields unchanged...? I'm less sure about the steps in ubuntu-clock-app though -- nik90, could you give this a little triage?

[Nekhelesh Ramananthan (nik90)]

I think I may have found the bug. On reading the SDK Alarms API documentation, it specifies that if the daysOfTheWeek are specified, then it will strive to trigger the alarms on that day. Let me illustrate an example here to explain.

Assume that the current date and time is Monday 15th April 10:00 AM, if the user tries to set an alarm to trigger everyday Mon-Fri at 08:30 AM, the alarm cannot trigger on 15th April Monday since that time has already passed. So the alarms API then tries the next possible date which is 21st April Monday at 08:30 AM which is a valid time instead of triggering the alarm on Tuesday 16th April.

So this is a bug in the ubuntu clock app due to the way it creates new alarms.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Yes, this seems working in the latest image #22

[Nekhelesh Ramananthan (nik90)]

This appeared fixed during my testing as well on image #24.

[Charles Kerr (charlesk)]

Marking as fixed based on personal testing and the above comments.