[datetime] Standard alarms are not work correctly for Timers, after timezone/DST change

Bug #1512180 reported by Bartosz Kosiorek
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Incomplete
Undecided
Unassigned
Timer
Confirmed
Undecided
Unassigned
Ubuntu Clock App
Incomplete
Medium
Unassigned
indicator-datetime (Ubuntu)
Invalid
Undecided
Unassigned
ubuntu-ui-toolkit (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Standard alarms will not work correctly after changing timezone and during DST change.

Steps to reproduce:
1. Install Timer from Store: https://uappexplorer.com/app/timer.mivoligo
2. Set timer to 5 minutes
3. Open Clock app. Look for alarm, and notice that alarm is correctly set
3. Switch to System Settings -> Time & Date -> Time zone:
4. Change Time zone to something different (eg. New York). (Or wait for DST change: https://en.wikipedia.org/wiki/Daylight_saving_time)

Expected behaviour:
- timer ringing as expected after timezone/DST change

Current behaviour:
- alarm is not ringing. (you could check active alarms in "Ubuntu Clock app)

Proposal solution:
- introduce new type of alarms, which is based on UTC (https://en.wikipedia.org/wiki/Coordinated_Universal_Time) and independent from time zones.
- This alatms will not be visible in applications which is using standard alarms (Ubuntu Clock, Ubuntu Calendar etc.)

description: updated
summary: - Standard alarms will not work correctly after changing timezone and
- during DST change
+ Standard alarms will not work correctly for Timers, after timezone/DST
+ change
no longer affects: ubuntu-clock-app (Ubuntu)
summary: - Standard alarms will not work correctly for Timers, after timezone/DST
- change
+ [datetime] Standard alarms will not work correctly for Timers, after
+ timezone/DST change
Changed in ubuntu-clock-app:
importance: Undecided → High
importance: High → Medium
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: [datetime] Standard alarms will not work correctly for Timers, after timezone/DST change

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

Changed in indicator-datetime (Ubuntu):
status: New → Confirmed
description: updated
summary: - [datetime] Standard alarms will not work correctly for Timers, after
+ [datetime] Standard alarms are not work correctly for Timers, after
timezone/DST change
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

Not sure I understand why this is not just an issue fr the timer app. Alarms want to be interpreted in local time, I am sure this is as designed. Timers are not really alarms as they reflect a duration not a time of day. For me the issue is the timer app implemented timers incorrectly.

Changed in canonical-devices-system-image:
status: New → Incomplete
Changed in timer:
status: New → Confirmed
Zsombor Egri (zsombi)
Changed in ubuntu-ui-toolkit (Ubuntu):
status: New → Incomplete
Revision history for this message
Bartosz Kosiorek (gang65) wrote :

Unfortunately we cannot fix that in Timer. When we are set new alarm for 9.00 AM, the alarm will ring at 9.00 AM local time.
Example:
1. Let's say we would like to set Timer for 15 minutes and local time 9.00 AM Timezone +0
2. From Timer, we are setting up alarm for 9.15 AM Timezone +0
3. Now we are changing time zone to -1, so the local time will be 8.00 AM Timezone -1
4. Alarm will be the same, so 9.15 AM Timezone -1

Current result:
  - Alarm/Timer will start ringing for 1 hour and 15 minutes

Expected result:
  - Alarm/Timer should start ringing always after 15 minutes, and should not be dependent from timezone

For timer we would like to ring in absolute time (UTC), not dependent from time zone.
Maybe there is some way to setup alarm in UTC?
If yes, I would love to implement that in Timer.

Revision history for this message
Charles Kerr (charlesk) wrote :

To start at the low level and working up:

ICAL

one way to handle a timer like this would be to anchor the timer in the originating timezone, then to define the trigger relative to that. for example, the ical event:
1. would have the start time equal to the creation time
2. would have the start/creation time specified with a specific timezone, eg nonfloating, so that point in time stays the same even when the user crosses timezones
3. set the trigger to execute 15 minutes after the start time; eg. a VALARM containing "TRIGGER;RELATED=START:P15M"

So in Bartosz's example in comment #3, this would effectively say "X is 15 minutes after 9.00 AM Timezone +0, trigger this alarm at X+15 no matter what timezone the user's in when X+15 happens."

QOrganizer

Our ical is currently generated by EDS, and our QOrganizer-to-EDS converter is in qtorganizer5-eds. Looking at the relevant code there, eg <http://bazaar.launchpad.net/~phablet-team/qtorganizer5-eds/trunk/view/head:/organizer/qorganizer-eds-engine.cpp#L2411>, this this kind of trigger will be created from a QOrganizerItem that has a QOrganizerItemReminder with a visual or audible component and which uses a relative offset via QOrganizerItemReminder::secondsBeforeStart().

Ubuntu-ui-toolkit

It doesn't look like this is currently supported in ubuntu-ui-toolkit. Its UCAlarm creates QOrganizerItemReminders in AlarmDataAdapter::setMessage() <http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/src/Ubuntu/Components/plugin/adapters/alarmsadapter_organizer.cpp#L107> and AlarmDataAdapter::setSound() <http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/src/Ubuntu/Components/plugin/adapters/alarmsadapter_organizer.cpp#L156> but in both cases it explicitly calls reminder.setSecondsBeforeStart(0).

So if you're using QOrganizer directly, you should be able to craft your QOranizerItemReminders s.t. this can work without any platform changes. If this needs to be implemented through UCAlarm, then we'll need new code in ubuntu-ui-toolkit.

Charles Kerr (charlesk)
Changed in ubuntu-ui-toolkit (Ubuntu):
status: Incomplete → Confirmed
Changed in indicator-datetime (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.