Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Adjusting for Local Time

Rank

Total Posts: 6

Joined 0

PM

I’m reading FIT files (currently from a Garmin Edge 500) using the decode.c example. I’m trying to figure out local time versus UTC time.

It looks like the times in the “session message” (e.g., timestamp, start_time, etc) and the times in the “record message” (i.e., timestamp) are in UTC. I’d like those times in local time.

I see the comment in the source code saying that FIT_LOCAL_DATE_TIME (i.e., local_timestamp in the “activity message”) can be used to convert timestamps to local time if the device doesn’t support time zones.

Two questions:
1. Is the best practice to compare the FIT_LOCAL_DATE_TIME in the “activity message” with the start_time in the “session message” and use this to adjust the timestamps in the “activity messages”?
2. How can I tell if a device supports time zones?

Thanks!      
Avatar
Rank

Total Posts: 7

Joined 2012-02-22

PM

FIT data has consciously been stored in UTC to provide a consistent reference for all data users. Leaving it in UTC makes it straightforward for any consumer of FIT data to display it in local time if so desired. Do you have an application where it’s necessary to display in the file creator’s local time?

The recommended practice for exposing the local timezone is logging at least one message that contains both a timestamp and local_timestamp field (such as activity or monitoring_info message).

If your activity message contains the optional local_time field, compare it to the timestamp field in the same message. Don’t compare it to the session message, it may not refer to the same epoch.

There is no general way to tell if a device supports time zones.      
Rank

Total Posts: 6

Joined 0

PM

Thanks pilsworth.

Yes, I'm developing an app that needs to display times in the file creator's time zone.

Reading an activity record from an Edge 500 (using the C SDK), the timestamp was correctly 714,058,903 (08/16/2012) but the local_timestamp was 3,435,973,836 (11/17/1998).

I tried several other FIT files and the local_timestamp in the activity records seemed like an uninitialized variable (i.e., > 3,000,000,000 and it remained the same for the program session). The csv file from that SDK example had 10,000+ records (everything from the battery level), but no local_timestamps.

I added a case for the monitoring_info message and didn’t receive any (and I suspect there isn’t one in the fit file).

Any other ideas? I think I may have to implement this client side (i.e., ask the user the UTC offset), but I’d really prefer to do it programmically.

Thanks.

FWIW, I'm attaching a FIT file that I'm working with.      
Rank

Total Posts: 6

Joined 0

PM

Received a message when submitting my post that file attachements are limited to a few file extensions. Triing again with a zip file. [file name=SachelisFIT.zip size=91948]http://www.thisisant.com/images/fbfiles/files/SachelisFIT.zip[/file]      
Avatar
RankRankRankRank

Total Posts: 296

Joined 0

PM

I've calculated the time zone offset from the local time stamp (field #5) of the activity message.
This field is however not set by all (Garmin) devices. So obviously there is no solution that works for all devices.

EDITED to correct an incorrect information in my original post ("there's a TZO field in activity messages")      
Rank

Total Posts: 6

Joined 0

PM

Thanks Old Man.

Field #5 in the activity record is the field that I mentioned appears to have unitialized data. Is it easy for you to run the sample fit file I uploaded and see if the field looks valid? I'm unsure if the problem is in the file or the c SDK.

Thanks!

[Another old man cyclist]      
Avatar
Rank

Total Posts: 7

Joined 2012-02-22

PM

-Sachelis

I looked at the attached .fit file and wasn’t able to determine the local time. The only message of interest is the activity message but the local_timestamp field is not included. Look at the definition message for local message 10, its has 6 fields: timestamp, total_timer_time, num_sessions, type, event and event_type.

It seems if you try to request a missing field in the C SDK you will get ‘invalid’ which for local_date_time (uint32) is 0xFFFFFFFF i.e. 4294967295, your fixed number > 3,000,000,000 (I can’t explain 3,435,973,836, can you recheck this one?).      
Avatar
Rank

Total Posts: 7

Joined 2012-02-22

PM

-OMB
I didn’t see TimeZoneUTCOffset in the activity message definition. Are you perhaps talking about device_settings.utc_offset? I haven’t seen a real example of this but my understanding is this field is used to transform timestamps < 0x10000000 (ie “system times” => seconds since reset, when the time is unknown or hasn’t been set yet). If you add the utc_offset you should be able to transform “system time” timestamps into “utc” timestamps.      
Rank

Total Posts: 6

Joined 0

PM

Thanks for helping me with this, pilsworth.

pilsworth wrote:
-Sachelis
<snip>
It seems if you try to request a missing field in the C SDK you will get ‘invalid’ which for local_date_time (uint32) is 0xFFFFFFFF i.e. 4294967295, your fixed number > 3,000,000,000 (I can’t explain 3,435,973,836, can you recheck this one?).


With this and several other Garmin fit files I consistently get 3,435,973,836. I tried casting activity->local_timestamp to a char pointer looking for "invalid", but I basically got garbage. Maybe I was casting it incorrectly. FWIW, I'm compiling with Unicode chars which might affect the string I'd see casting the FIT_LOCAL_DATE_TIME pointer (I tried casts to TCHAR, char, etc).

pilsworth wrote:
-Sachelis

<snip>
OMG. I didn’t see TimeZoneUTCOffset in the activity message definition. Are you perhaps talking about device_settings.utc_offset? <snip>


I no longer see OMB's post. But in my case, I'm trying to determine local time in files created by others and I can't write the offset into the file).

FWIW, when I import this sample file into other apps, they do adjust for the time zone. (E.g., I just did a clean install of Golden Cheetah on a PC, imported this one file without the device connected [so GC couldn't look in other files], and it imported with local time--maybe GC got the UTC offset from the OS.)