MarcoBuster/Gadgetbridge
1
0
Fork 0
mirror of https://codeberg.org/Freeyourgadget/Gadgetbridge synced 2024-12-26 10:35:50 +01:00
Code Releases Wiki Activity

Back out the DST handling, since it causes problems with activity fetching

Browse Source 
Details: when we ask to fetch activity samples from date:time:tz+dst, the band,
under certain conditions, will send us back date:time:tz (without the dst offset)

We're fine with that, so we start fetching. When it's done, we take the last sample's
timestamp (still without dst offset), convert it to a unix timestamp, create a Calendar
using current tz and apply the unix timestamp. Then we send that timestamp again to the
band in order to fetch activity samples from then, but we again add the dst offset to the tz,
so send as date:time:tz+dst without changing the timestamp. That way, we may end up at the
timestamp we began with, fetching the same activity data again and not progressing.

We first need to thorougly understand how the devices behave, before we can reenable and fix
this.
This commit is contained in:
cpfeiffer 2017-11-07 21:24:48 +01:00
parent b76e78768c
commit da7de378d3
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/btle/BLETypeConversions.java
View File

@ -265,7 +265,7 @@ public class BLETypeConversions {
*/ */
public static byte mapTimeZone(TimeZone timeZone, int timezoneFlags) { public static byte mapTimeZone(TimeZone timeZone, int timezoneFlags) {
int offsetMillis = timeZone.getRawOffset(); int offsetMillis = timeZone.getRawOffset();
if (timezoneFlags == TZ_FLAG_INCLUDE_DST_IN_TZ) { if (false && timezoneFlags == TZ_FLAG_INCLUDE_DST_IN_TZ) {
offsetMillis += timeZone.getDSTSavings(); offsetMillis += timeZone.getDSTSavings();
} }
int utcOffsetInHours = (offsetMillis / (1000 * 60 * 60)); int utcOffsetInHours = (offsetMillis / (1000 * 60 * 60));