In the add_weigh_in library, when a timestamp is passed, the function disregards the timezone information in the timestamp and calculates based on the local timezone.
For instance, if I wish to record my weight for my local time in AEST, I might use the following command:
garmin.add_weigh_in(weight=100, unitKey='kg', timestamp='2023-09-01T14:34:25.518993+11:00')
This works as expected when executed on a local machine set to AEST timezone. However, when the same code is run on a server (which typically operates in UTC as its local timezone), it produces unexpected outcomes in Garmin Connect.
The underlying issue is associated with the use of astimezone() in the following line of code:
dtGMT = dt - dt.astimezone().tzinfo.utcoffset(dt)
This line overlooks the timezone in the provided timestamp, defaulting to the server's timezone.
A more straightforward and effective solution would be:
dtGMT = dt.astimezone(timezone.utc)
In the add_weigh_in library, when a timestamp is passed, the function disregards the timezone information in the timestamp and calculates based on the local timezone.
For instance, if I wish to record my weight for my local time in AEST, I might use the following command: garmin.add_weigh_in(weight=100, unitKey='kg', timestamp='2023-09-01T14:34:25.518993+11:00')
This works as expected when executed on a local machine set to AEST timezone. However, when the same code is run on a server (which typically operates in UTC as its local timezone), it produces unexpected outcomes in Garmin Connect.
The underlying issue is associated with the use of astimezone() in the following line of code: dtGMT = dt - dt.astimezone().tzinfo.utcoffset(dt)
This line overlooks the timezone in the provided timestamp, defaulting to the server's timezone.
A more straightforward and effective solution would be: dtGMT = dt.astimezone(timezone.utc)