Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamps don't have timezone information #3

Open
Tigge opened this issue Jan 15, 2012 · 11 comments
Open

Timestamps don't have timezone information #3

Tigge opened this issue Jan 15, 2012 · 11 comments
Assignees

Comments

@Tigge
Copy link

Tigge commented Jan 15, 2012

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
Copy link
Owner

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

@ghost ghost assigned dtcooper Jan 17, 2012
@dtcooper
Copy link
Owner

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
Copy link
Author

Tigge commented Jan 31, 2012

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
Copy link
Owner

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
Copy link
Owner

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

@pR0Ps
Copy link
Collaborator

pR0Ps commented May 29, 2017

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
Copy link
Contributor

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
Copy link
Contributor

polyvertex commented Jan 20, 2018

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
Copy link

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
Copy link

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
Copy link
Collaborator

dlenski commented Oct 5, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants