Garmin API and timezones

[kylesayrs]

Hi there,

I'm not sure if Garmin has any documentations for their apiconnect api, but from your experience do you know anything about how the api handles time zones? It seems to me that the API uses GMT by default. If the API always returns in the GMT zone, or this is modifiable in the request, either way it would be nice if this tzinfo was embedded in the datetime objects that are returned.

Looking forward to hearing your thoughts!

[matin]

hi @kylesayrs , sorry for the slow response.

If you take a look at DailySleepDTO, you'll see how there are cases where Garmin is returning the sleep start and end time in both GMT and local. I'm not actually sure how this works if you fall asleep in one timezone and wake up in another such as in the case of regions with daylight savings or falling asleep on a flight.

Specifically in the case of sleep, there are properties for DailySleepDTO.sleep_start() and DailySleepDTO.sleep_end() that use DailySleepDTO._get_localized_datetime() to return datetime objects with the correct timezone.

    def _get_localized_datetime(
        self, gmt_timestamp: int, local_timestamp: int
    ) -> datetime:
        local_diff = local_timestamp - gmt_timestamp
        local_offset = timezone(timedelta(milliseconds=local_diff))
        gmt_time = datetime.fromtimestamp(gmt_timestamp / 1000, timezone.utc)
        return gmt_time.astimezone(local_offset)

    @property
    def sleep_start(self) -> datetime:
        return self._get_localized_datetime(
            self.sleep_start_timestamp_gmt, self.sleep_start_timestamp_local
        )

    @property
    def sleep_end(self) -> datetime:
        return self._get_localized_datetime(
            self.sleep_end_timestamp_gmt, self.sleep_end_timestamp_local
        )

Other than sleep, is there another scenario where this would be useful?

[matin]

@kylesayrs are there any scenarios other than sleep where this is an issue? if not, we can close this

[matin]

closing issue as it's unclear in what cases we should account for timezones other than sleep, which is already addressed

[jpms4]

I have got another issue regarding timezones and I wonder whether you know how Garmin deals with it. When you travel between time zones (Continental Europe to UK) and during seasonal time change (last Sunday in October), the endpoints for steps yields 92 values instead of 96, which is quite confusing as the timestamps are in any case GMT-based. During the generation of daily steps data, however, local time (starting at 23:00 h the day before for local European time or 22:00 h respectively in summer) is considered when creating the responses per date.
Interestingly, the Garmin Connect App does not lack any data on those days, so the orginal data might exist, but not be provided through the endpoints.