Activity Tracker history - values are incorrect

Hi all,

Has anyone experienced the following:
1. There is no history for the activity tracker in the simulator. Very frustrating as you have to deploy to actual device to test every small change. Am I doing something wrong?

2. When you get the history (Act.getHistory()), an array of 7 History objects is returned. One of the fields (startOfDay) gives you a Moment object. I take this moment object and convert this to a Calendar info object (var info = Calendar.info(aHist.startOfDay, Time.FORMAT_LONG);). Now for my real question...

When I get info.day, the value is correct. But when I use info.day_of_week, I get the wrong day corresponding to the value returned from info.day. Any ideas?

Thanks

travis.vitek over 10 years ago

I'm almost certain that if you look at the full date that is returned you'll find it is for a different date.

scoetser75 over 10 years ago

Hey Travis, you are correct. Any pointer on converting the Moment number to the actual date it represents?

Thanks

scoetser75 over 10 years ago

Further to this, can someone please clarify why the history object return the following values? I circulate through the array backwards (starting at position 6 o fthe zero based array) as that is the oldest item. I wants to display oldest to newest from left to right. Here is the result set...

(6)18 Mar 1995 - steps and goals is actual for 17 Mar 2015
(5)17 Mar 1995 - steps and goals is actual for 16 Mar 2015
etc.

So it look slike the Moment field is not correct based on UTC time returned.

Help please!

travis.vitek over 10 years ago

It isn't clear from the documentation, but some times are equivalent to a normal Unix UTC timestamp (the epoch is 1970-01-01T00:00:00Z) and others are using the Garmin epoch (1990-01-01T00:00:00Z). You'll have to offset the time in the history by the number of seconds between these times. I'm pretty sure that the activity history value is a unix timestamp but the Gregorian.info() method expects a Garmin timestamp, so you'd need to subtract 631152000 (I may be off by 24 hours).

I originally found and mentioned it here.

Travis

Former Member over 10 years ago

These values shouldn't have been returned with Garmin epoch. I've created a ticket to correct these values to UNIX epoch.

travis.vitek over 10 years ago

Is this is one of those things that if you change the behavior you'll cause breakage for applications that are run on old firmware?

Former Member over 10 years ago

If an app is currently using this API and compensating for the incorrect epoch, then fixing this error will cause that app to display incorrect dates. I think we will just make this correction because the API is not behaving to the specification (we are not changing the specification).

If you find any other APIs that are using the Garmin epoch, please report it as a bug, and if possible avoid correcting for these bugs. ConnectIQ does not document this epoch and should not be providing any Moment objects that do not use UNIX epoch.

Former Member over 10 years ago

Travis,

We are in the process of fixing this issue, and wanted to comment more specifically on what to expect.

Because the product release cycles are not synchronized, it is likely this issue (and other issues) will be fixed in devices at varying times. If you are actively this portion of the API, I recommend treating the data as UNIX epoch as all devices will eventually return the data in that format as intended.

For this API in particular, you could also take advantage of the nature of the data being returned. In this case, I recommend compensating for the erroneous time epoch only if the date returned is prior to the release of our ConnectIQ devices.

Brandon.ConnectIQ over 10 years ago

The fix for this issue is available in the 1.1.1 SDK release. Like Brian mentioned, the fix may not be available in device firmware for a little while.