- From: Gene Lian <clian@mozilla.com>
- Date: Wed, 13 Nov 2013 00:07:03 -0800 (PST)
- To: public-sysapps@w3.org
- Cc: ch.dumez@sta.samsung.com, Marcos Caceres <mcaceres@mozilla.com>, Mounir Lamouri <mounir@lamouri.fr>
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
Received on Thursday, 14 November 2013 00:53:36 UTC