Thank Paul for the valuable information. Yes, this issue is probably caused by the time zone setting. When I set the system time zone to the *Daylight saving time* such as the PDT(pacific daylight time) or EDT(eastern daylight time), the REPEAD alarm has 3600 seconds gap. However if I set the system time zone to standard time such as the EST(eastern standard time) or UCT, the 3600 seconds gap is gone and the alarm is working well.
So the basic conclusion is that the 3600 seconds gap is caused by the Daylight saving time setting. I suggest to log a JIRA bug to track this issue. Thanks, Jingfu From: Hanchett, Paul [mailto:[email protected]] Sent: Wednesday, June 18, 2014 7:25 AM To: Ye, Jingfu Cc: [email protected] Subject: Re: [Dev] Tizen alarm API issue - REPEAT alarm finds 3600 seconds gap on the initial trigger time 3600 seconds is suspicious-- Could it have something to do with time zones or daylight savings settings? Paul Paul Hanchett ------------------- Infotainment Engineer MSX on behalf of Jaguar Land Rover One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, Oregon, 97204 Email: [email protected]<mailto:[email protected]> ------------------- Business Details: Jaguar Land Rover Limited Registered Office: Abbey Road, Whitley, Coventry CV3 4LF Registered in England No: 1672070 On Tue, Jun 17, 2014 at 1:27 AM, Ye, Jingfu <[email protected]<mailto:[email protected]>> wrote: Hello, When I am implementing the *Alarm API* (https://developer.tizen.org/dev-guide/2.2.1/org.tizen.web.device.apireference/tizen/alarm.html) in the tizen extension, I observe the following two core alarm APIs, which are declared in the “app_alarm.h” file, seem not working as excepted. When I call either of them by passing a positive (non-zero) value to the *period* argument to generate a REPEAT alarm, this alarm’s initial trigger time is postponed 3600 seconds after the expected trigger time. -- int alarm_schedule_at_date(service_h service, struct tm *date, int period, int *alarm_id); int alarm_schedule_after_delay(service_h service, int delay, int period, int *alarm_id); -- For example, if I have the call: alarm_schedule_after_delay(aService, 20, 15, &alarmId); the scheduled alarm should assumed to initially be triggered in 20 seconds. However it’s actually triggered in 3620 seconds. The alarm_schedule_at_date() would see the very similar result. On the other hand, if I pass zero to the *period*, it’s working correctly.( E.g. it’s triggered in 20 seconds in this sample.) I am not quit clear why there is the extra 3600 seconds before the initial trigger. And this is just happening on the REPEAT alarm. I post here my sample code in the case if I miss something in my implementation. -- int main(int, const char **) { service_h service = NULL; int alarmId = 0; int delay = 20; // seconds int period = 15; // seconds std::string appId = “xwalk.igmalgolbemdploocjilliolbandbblg”; service_create(&service); service_set_app_id(service, appId.c_str()); service_set_app_id(service, SERVICE_OPERATION_DEFAULT); alarm_schedule_after_delay(service, delay, period, &alarmId); service_destroy(service); return 1; } -- How can I get some assistance to resolve this issue? Let me know if you have idea to address this issue. Thank you in advance. Thanks, Jingfu _______________________________________________ Dev mailing list [email protected]<mailto:[email protected]> https://lists.tizen.org/listinfo/dev
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
