search

precisely / curious2

0 stars 0 forks source link

Time zone of imported data from devices #187

Closed syntheticzero closed 10 years ago

syntheticzero commented 10 years ago

See email:

From: Kimberly Davis kim@wearecurio.us Subject: Fitbit problem, characterized... Date: February 18, 2014 at 6:02:19 PM EST To: Mitsu Hadeishi mitsu@wearecurio.us

One of my Rps is an IT guy. He recently wrote me this email:

Kimberly,

Swadha and I just realized that the integration into Fitbit may actually be broken because of time-zone difference calculations. We have noticed that our FITBIT data is presented in the webstudy.

We both noticed that our current Fitbit info is showing in the previous days' information, with a default time-stamp of 10:00pm. I think the difference is because FitBit would be presenting the time in local-time-zone, and your API is trying to then again take the local time, presuming it's in GMT, reducing an additional 07:00 hours, thereby making a total difference of about 14-16 Hrs.

It would be great, if you could please have your back-end team, verify the tamp-stamps and test.

syntheticzero commented 10 years ago

Looking at the source code, I see that the date formatters are indeed not setting the time zone correctly. They should be using the time zone of the user, as obtained from a GetUserInfo call. Note -- this same time zone logic should be used for all devices, including Withings and Moves, etc.

Note that we do have a User.getTimeZoneId() call now, but this call should be used only if there is no time zone available from the service, because it uses the last time zone recorded by a user entry, so it's not as accurate as the device time zone.

sagrawal31 commented 10 years ago

Implementation Notes

Issues Covered

  1. Fix for withings refresh subscription & poll job,
  2. Fix for timezone problem for parsing date #187,
  3. Withings Activity data metrics data import #177 #154,
  4. Setting accessToken to blank if token expires to display user to re-link with api.

About Timezone fix

Added a new nullable column timeZoneId in OAuthAccount domain, which will be populated at time of subscription.

For FitBit, Moves & Human API, timezone are fetched from user profile data. 23AndMe import does not require timezone, so skipping timezone for it & also it doesn't sends timezone in user profile response.

For Withings API, timezone is only sent in activity data metrics, so for storing timezone of the user, added a hack for the API. While authenticating, first fetching activity data for previous day & searching timezone from first record. If its available then returning it else fetching activity data for past 3 month & searching same for first record.

If user don't have any activity metrics data available for past 3 months from day of subscription then setting default timezone for the user.

syntheticzero commented 10 years ago

Deployed