touch-packages team mailing list archive

[Charles Kerr <charles.kerr@xxxxxxxxxxxxx>]

"X-EVOLUTION-ENDDATE" is set only in one place, evolution-data-
server/calendar/libecal/e-cal-recur.c's function ,
e_cal_recur_set_rule_end_date(), which is only called in this block:

>        /* Calculate the end date. Note that we initialize end_date to 0, so
>         * if the RULE doesn't generate COUNT instances we save a time_t of 0.
>         * Also note that we use the UTC timezone as the default timezone.
>         * In get_end_date () if the DTSTART is a DATE or floating time, we will
>         * convert the ENDDATE to the current timezone. */
>        cb_data.count = rule.count;
>        cb_data.instances = 0;
>        cb_data.end_date = 0;
>        e_cal_recur_generate_instances_of_rule (
>                comp, prop, -1, -1,
>                e_cal_recur_ensure_rule_end_date_cb,
>                &cb_data, tz_cb, tz_cb_data,
>                icaltimezone_get_utc_timezone ());
>
>        /* Store the end date in the "X-EVOLUTION-ENDDATE" parameter of the
>         * rule. */
>        e_cal_recur_set_rule_end_date (prop, cb_data.end_date);

It looks like somehow e_cal_recur_generate_instances_of_rule() here
generated no instances so that end_date became the epoch.


** Changed in: indicator-datetime (Ubuntu)
     Assignee: (unassigned) => Charles Kerr (charlesk)

** Description changed:

  I'm not sure yet what's causing this, but the symptom is for
  ~/.local/share/evolution/tasks/${foo}@ubuntu-phablet/tasks.ics to have
  entries whose rrule looks like this:
  
  > RRULE;X-EVOLUTION-ENDDATE=19700101T000000Z:FREQ=WEEKLY;COUNT=32639;
  >  BYDAY=MO,TU,WE,TH,FR
  > SUMMARY:Weekday wakeup
  
  When is should look more like this:
  
  > RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
  
  Alarms appear / trigger again after manually editing tasks.ics to remove
  the invalid X-EVOLUTION-ENDDATE and COUNT values, then restarting
  evolution-calendar-factory and indicator-datetime.
  
  ENDDATE's clearly coming from a (time_t)0. Not sure about 32639, but
  it's INT16_MAX - 128, so we've got that.
+ 
+ Edit: this doesn't appear to be the full story -- if I create a brand
+ new recurring alarm it works correctly even though the epoch ENDDDATE is
+ present. For me they disappeared later, after a few days had passed and
+ the system had been rebooted dozens of times. I'll see if I can
+ reproduce the bug and, if so, how to reproduce it.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to indicator-datetime in
Ubuntu.
https://bugs.launchpad.net/bugs/1424924

Title:
  clock-app alarms' RRULE have unusual X-EVOLUTION-ENDDATE, causing
  alarms to not sound

Status in indicator-datetime package in Ubuntu:
  New
Status in qtorganizer5-eds package in Ubuntu:
  New
Status in ubuntu-clock-app package in Ubuntu:
  New

Bug description:
  I'm not sure yet what's causing this, but the symptom is for
  ~/.local/share/evolution/tasks/${foo}@ubuntu-phablet/tasks.ics to have
  entries whose rrule looks like this:

  > RRULE;X-EVOLUTION-ENDDATE=19700101T000000Z:FREQ=WEEKLY;COUNT=32639;
  >  BYDAY=MO,TU,WE,TH,FR
  > SUMMARY:Weekday wakeup

  When is should look more like this:

  > RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR

  Alarms appear / trigger again after manually editing tasks.ics to
  remove the invalid X-EVOLUTION-ENDDATE and COUNT values, then
  restarting evolution-calendar-factory and indicator-datetime.

  ENDDATE's clearly coming from a (time_t)0. Not sure about 32639, but
  it's INT16_MAX - 128, so we've got that.

  Edit: this doesn't appear to be the full story -- if I create a brand
  new recurring alarm it works correctly even though the epoch ENDDDATE
  is present. For me they disappeared later, after a few days had passed
  and the system had been rebooted dozens of times. I'll see if I can
  reproduce the bug and, if so, how to reproduce it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1424924/+subscriptions