Timestamps don't have timezone information

[Tigge]

I don't know if FIT-files keep timezone information or if one is implied somehow. If that is the case it would be nice to have timezone information in the datetime objects created by fitparse.

[dtcooper]

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

[dtcooper]

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.

[Tigge]

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.

[dtcooper]

Hey Tigge, I'm currently in the process of updating the library. Any sample files with and a description of expected behaviour sent to [email protected] would be very much appreciated!

Thanks,

David

[dtcooper]

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

[pR0Ps]

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?

[polyvertex]

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.

[polyvertex]

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

[dukeduck1984]

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.'

[dukeduck1984]

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).

[dlenski]

I recently submitted a PR to @Tigge's FIT-to-TCX, Tigge/FIT-to-TCX#13, which makes it test that all of the files from this project's test/files can at least be translated to TCX without failures.

antfs-dump.63.fit turns out to be a really interesting one, because it's from a non-GPS HRM device. The only "real" timestamp (integer value > 0x1000000) is the local_time_stamp from the activity:

2. activity
 * event: activity
 * event_type: stop
 * local_timestamp: 2012-02-13 12:21:03
 * timestamp: 16444673 [s]
 * type: manual

These two values (2012-02-13T12:21:03+??:?? and 16444673 seconds since power-on) refer to the same moment in time. So the value of the local_timestamp can be used to calibrate the correct offset for all the other integer-value timestamps in the file. The major caveat to this is that, because the local_timestamp is in local time, and there's no GPS data and no TZ offset, we don't actually have any idea what timezone everything is in. 🤷‍♂️ 🤕

I implemented this offset-adjusting in Tigge/FIT-to-TCX@4a8e0e8, but perhaps it would be appropriate to include it in python-fitparse?

Something like a translate_integer_timestamps() function to find all the integer timestamps in the FIT-file messages, and translate them into datetime by using whatever local_timestamp or UTC timestamps do exist in the file. I can write a PR for this if interested.