Look at the bottom of fitparse/records.py (lines 289-297):

# Custom conversion functions for FieldTypes (specific to FIT SDK 1.2)

# TODO:
#   "0x10000000: if date_time is < 0x10000000 then it is system time (seconds
#   from device power on)" -- not ofr local_date_time
_convert_date_time = lambda x: datetime.datetime.fromtimestamp(631065600 + x)

# TODO: Handle local tz conversion
_convert_local_date_time = lambda x: datetime.datetime.fromtimestamp(631065600 + x)

Hmmmm... I'm not sure TZ is information held in the .FIT file. For now, it just uses your local system time for both date_time field types. Let me think about this a bit.

D

My .FIT from the Garmin Edge 500 files just hold time relative to their current as far as I can tell. Do you have any example files to share? I could support this.

I'm using python-fitparse to for FIT-to-TCX and would like to get some timezone information in there. I have some fit files from my Garmin Forerunner 610, I'll see if I can send some over to you.

Hey Tigge, I'm currently in the process of updating the library. Any sample files with and a description of expected behaviour sent to dave@kupesoft.com would be very much appreciated!

Thanks,

David

*any sample files from your Forerunner 610 and a description of expected behaviour...

This is a hard problem because (as far as I can tell from reading the docs) there is no "device timezone" information supplied anywhere in the FIT file.

Decoding used to just assume the device was in the computer's local timezone. As of b43005d this was changed to assuming UTC. Both are invalid assumptions but at least assuming UTC will give you consistency.

One method to get a mostly correct result would be to look for a record that has both a local_timestamp and timestamp fields, then use the difference to calculate the device's local offset.

Really, the only really 100% correct way would be to require a device timezone to be passed into the constructor. If one isn't supplied, then there's no way to ensure that the library is outputting correct times. At that point maybe it should log a warning and not emit any local_timestamp fields at all?

@dtcooper Thoughts?

Late jump in but in case it helps: according to the Profile.xlsx file from the ANT SDK as well as its documentation, values of the date_time type are given in UTC. There is a separate type for local time: local_date_time, that is spit in some messages.

Therefore for correctness and consistency, I guess fitparse should always make its datetime.datetime objects "timezone aware" by either specifying UTC as a timezone, or the offset found in the FIT message.

Oh, it seems fitparse's data processor is context-less so the timezone offset of a local_date_time value cannot be deduced without significant modifications :(
Sorry for the noise

In the 'activity' message .get_meesages('activity') you will find a field called 'local_timestamp'. Its description, according to the FIT File Types in the SDK, is 'Timestamp epoch expressed in local time. Used to determine the time_zone or convert timestamps to local time.'

I came across a .fit file recorded by a Garmin Edge 510 which didn't have the 'local_timestamp'. Another way to work around this is to use the latitude and longitude data to get the timezone info (there are a couple of packages available for this).