From da7de378d390e0ea8f70181aefffcb40df4b6976 Mon Sep 17 00:00:00 2001 From: cpfeiffer Date: Tue, 7 Nov 2017 21:24:48 +0100 Subject: [PATCH] Back out the DST handling, since it causes problems with activity fetching 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. --- .../gadgetbridge/service/btle/BLETypeConversions.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/btle/BLETypeConversions.java b/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/btle/BLETypeConversions.java index 71dff949c..47b46a172 100644 --- a/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/btle/BLETypeConversions.java +++ b/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/btle/BLETypeConversions.java @@ -265,7 +265,7 @@ public class BLETypeConversions { */ public static byte mapTimeZone(TimeZone timeZone, int timezoneFlags) { int offsetMillis = timeZone.getRawOffset(); - if (timezoneFlags == TZ_FLAG_INCLUDE_DST_IN_TZ) { + if (false && timezoneFlags == TZ_FLAG_INCLUDE_DST_IN_TZ) { offsetMillis += timeZone.getDSTSavings(); } int utcOffsetInHours = (offsetMillis / (1000 * 60 * 60));