mirror of
https://codeberg.org/Freeyourgadget/Gadgetbridge
synced 2024-08-16 20:31:00 +02:00
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.
This commit is contained in:
parent
b76e78768c
commit
da7de378d3
@ -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));
|
||||
|
Loading…
Reference in New Issue
Block a user