Alarms are triggered in UTC tz despite saving in local tz

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

It seems some layer is interpreting the alarm time being requested as UTC instead of the local timezone, thereby scheduling it 5 hrs too far ahead. It looks like clock and the alarm api expect localtime although this is not explicit in the API doc.

We should ensure that timezone changes are reacted to properly for saved alarms. Perhaps all alarms should be saved in UTC and converted as appropriate.

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

@Charles, I am saving the event time in UTC formart using:

        ECalComponentDateTime *dt = g_new0(ECalComponentDateTime, 1);
        dt->value = g_new0(struct icaltimetype, 1);
        *dt->value = icaltime_from_timet(etr.startDateTime().toTime_t(), etr.isAllDay());
        e_cal_component_set_dtstart(comp, dt);
        e_cal_component_free_datetime(dt);

since there is no way to convert the time to localtime at this point, could you check if you can do that on the indicator.

Yep, I agree with Renato -- these are being saved in tasks.ics as floating times, ie, localtime.

I think this is a datetime bug rather than something in qtorganizer5-eds or ubuntu-ui-toolkit.

Actually my last comment was only half right. indicator-datetime does have a bug that doesn't set the fallback timezone for EDS to use when loading events, but there is a bigger problem in qtorganizer5-eds.

So, I'm in UTC-6 and just used ubuntu-clock-app to create a one-time alarm to kick on Wed Feb 27th at 9 PM. What gets saved to tasks.ics is this:

    DTSTART:20140227T030000
    DUE:20140227T030000
    SUMMARY:Alarm

Note the lack of timezone information. That makes this a "floating" time, meaning that the alarm will kick at that specified time regardless of timezone. This is a Good Thing, since that means our M-F 6am wakeup alarms will kick at 6am even if we travel to a different timezone.

So that's the good news. The bad news, the kick time is floating at 2014-02-27 03:00:00. That means EDS being sent a VTODO that kicks at 3am no matter what timezone it's in.... and that's why indicator-datetime is showing what it's showing.

To follow up on renato's comment #5... we could simply convert back from UTC to localtime in indicator-datetime, but that will only work correctly if you're running in the same timezone where the alarm was created.

And in fact we're already making this mistake in the clock app:

  1. create & save a new wakeup alarm to kick at 6am m-f
  2. exit ubuntu-clock-app
  3. kill all evolution processes to ensure everything in its cache gets flushed
  4. change to another timezone
  5. restart ubuntu-clock-app
  6. result: the alarm no longer kicks at 6am

We just agreed with renato that SDK Alarms will transform (not convert) the alarm time into UTC value, and set them as alarm values. So the fix will come from SDK.

Zsombor, could you expand on what "transform (not convert)" means here?

Ideally we would want alarms to all be floating times; ie, an alarm set to go off on Feb 28 at 6am would be "DTSTART:20140228T060000" with no trailing zulu on the timestamp, and with no TZID parameter in the entry.

I meant transform the local hour into exactly same UTC time (i.e. 3:00am UTC+2 onto 3:00am UTC). Would this be good enough? Or would this still contain TZ info?

Zsombor, I think so this is good enough for now, since qtorganizer5-eds currently generates all its icaltimes as floating (because of the use of with icaltime_from_timet()).

Given more time, it would be nicer to handle both floating and non-floating times there. But since the only current user is the alarms code, there's no reason to prioritize this work for 14.04.

FWIW, this also apparently makes it impossible to set an alarm for today if the current time is between midnight and the number of hours past UTC your time zone is.

So, I'm in UTC-6. It's 2am. I can't set an alarm to go off in 15 minutes (or any time before 6am), because it automatically sets the alarm for *tomorrow*. Even if I tell it to repeat every day of the week.

Zsombor, the patch you're working on generates tasks.ics entries like the one described in comment #10, right?

Yes, Charles, I'm giving the date to qtorganizer-eds transformed into UTC (i.e. 3pm Local time === 3pm UTC). Now, all tasks.ics entries are in UTC. But I guess we agreed that it is OK to have that. If not, eds plugin must do sthing with the time.

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

Fix committed into lp:~ubuntu-sdk-team/ubuntu-ui-toolkit/staging at revision 1010, scheduled for release in ubuntu-ui-toolkit, milestone Unknown

This bug was fixed in the package ubuntu-ui-toolkit - 0.1.46+14.10.20140502.6-0ubuntu1

---------------
ubuntu-ui-toolkit (0.1.46+14.10.20140502.6-0ubuntu1) utopic; urgency=low

  [ Tarmac ]
  * [ Zoltán Balogh]   * Skip tests only for powerpc   [ Christian Dywan
    ]   * Use locale format specifier in textfield_numbers. (LP:
    #1311907, #1283236, #1285958, #1124071, #1256424, #1276172,
    #1228042, #1183255, #1283212, #1168914, #1273187, #1276821,
    #1308086, #1288937, #1292601)

  [ Zoltán Balogh ]
  * [ Zoltán Balogh]   * Skip tests only for powerpc   [ Christian Dywan
    ]   * Use locale format specifier in textfield_numbers. (LP:
    #1311907, #1283236, #1285958, #1124071, #1256424, #1276172,
    #1228042, #1183255, #1283212, #1168914, #1273187, #1276821,
    #1308086, #1288937, #1292601)

  [ tpeeters ]
  * [ Zoltán Balogh]   * Skip tests only for powerpc   [ Christian Dywan
    ]   * Use locale format specifier in textfield_numbers. (LP:
    #1311907, #1283236, #1285958, #1124071, #1256424, #1276172,
    #1228042, #1183255, #1283212, #1168914, #1273187, #1276821,
    #1308086, #1288937, #1292601)
 -- Ubuntu daily release <email address hidden> Fri, 02 May 2014 16:31:41 +0000

Just confirming this works for me now, on image utopic 18.