Re: [Task Scheduler] Can we really remove TimezoneDirective argument?

Hi Gene,

I remember I already raised this issue during the Toronto F2F when it was first suggested we remove timezone support.
Mounir responded that the application would have to listen for timezone change events to support such use cases:
http://www.w3.org/2013/08/27-sysapps-minutes.html#item05 (You can search for " we can't do an alarm clock application")

So I would like to hear Mounir's feedback on this issue. I don't think we have any API to listen for timezone changes yet,
do we? (and time changes due to DST). Even then, this will be quite some work on application side

Overall, the task scheduler API is so simple (no recurrence, no timezone support) that I think it will require a lot of work
on application side to support use cases such as the ones for alarm clocks and calendars. While I like the fact that the
API is simple, I worry we are not doing a good enough job covering these more complex use cases.

However, the API easily supports use cases such as I want to launch myself in 10 minutes to check for new emails or I want
to lunch myself in 1 week to check for software updates.

Kr,
Christophe Dumez.

On 11/13/2013 03:07 AM, Gene Lian wrote:

Hi guys,

I'm trying to do prototyping by the new design of Task Scheduler API.
Eventually, I found out there is a potential issue that the current
design cannot properly handle.

In our original design we could input:

  enum TimezoneDirective {
    "respectTimezone",
    "ignoreTimezone"
  }

The "ignoreTimezone" is specifically used for allowing users to set
a task that can fire at a local time. For example, an alarm set as
7:00am will fire at 7:00am in Paris' local timezone or 7:00am in New
York's local timezone, which are different absolute time, depending
on which timezone the user is in.

However, the issue is, the Alarm Clock App cannot use the current
version of TaskScheduler API to add an alarm that can dynamically
adjust its absolute firing time according to what the current
timezone is, because the new design can only eat an absolute time
and the alarm will always fire at that universal time point.

To work with the current design, Alarm Clock App needs a way to
capture the system's timezone change to remove its previous alarm
and re-add it with a new time, which means the TaskScheduler API
is not really independent to use. Also, watching the system's
timezone change needs a more strict permission (i.e. settings).
However, TaskScheduler API can probably be exposed to those
third-party apps that don't have those system permissions.

I'd suggest adding that TimezoneDirective argument back to let the
API implementation take the responsibility of automatically
resetting the alarms whenever the system timezone gets updated.

I'd apologise for not raising this issue when we were wanting to
remove that. :( Some potential issues can only be found when we
really dive into the implementation.

What do you think?

Gene




--
Christophe Dumez - Samsung Telecommunications America