Find timezone information for non-GPS activities?

I think the answer is 'no', but is there a way to determine in which time zone non-GPS activities were recorded? Runalyze shows the start time of GPS activities just fine, but for indoor activities (that only have UTC time information) the start time is interpreted as in the current local timezone. I thought perhaps when a watch connected to a phone, maybe there is a field in the FIT file with the time zone information from the phone (but I can't find it).

  • If you open a FIT file in fitfileviewer.com, the Device Setting section has the following fields:

    - active time zone

    - utc offset

    - time offset (s)

    - time zone offset (hr)

    Unfortunately, for me, whether or not my activity was recorded with GPS or not, most of those values are either 0 or the binary equivalent of -1, in the case of time offset.

    It's conceivable that a CIQ data field app could record the value of System.ClockTime.timeZoneOffset() (which is the offset from UTC in seconds), but the problem there is that:

    - this offset includes DST, which may lead to ambiguity

    - the ClockTime.dst field, which could fix the above problem, is always set to 0 (it's supposed to be deprecated)

    For CIQ 3+ devices (which should be most devices released within the last 8 years), a CIQ data field could also access the time zone offset without DST using LocalMoment.getTimeZoneOffset(), but that would require the data field to store the last known GPS location (meaning it would have to be running during the last GPS activity.)

    Probably aren't any great solutions here.

  • Thank you for researching this. No great solutions indeed, I'll just have to keep making notes of what the local time was and change the times of non-GPS activities in Runalyze myself, it is already nice that it works for GPS activities.

    Better than the history on the watch: that shows all activties, with or without GPS, in the local time. I wonder what happens when you travel a long distance, activities could be shown on the wrong date perhaps. Would like to try by taking vacation in Australia! 

    Anyway, it's OK, from past development work I remember the infinte struggle of dealing with timezones, DST and user expectations. 

  • Anyway, it's OK, from past development work I remember the infinte struggle of dealing with timezones, DST and user expectations.

    Yeah, you would be shocked (or not) about some of the timezone bugs in Garmin products.

    e.g. If you convert UTC to local time for a date other than today, the DST rules for today are applied to the conversion. This is such a mind-boggling implementation (I've never seen anything like it in any other device which is supposed to have automatic support for timezones.) The funny thing is that they are devs in the CIQ forums who are willing to defend this decision to the death, even claiming that's how it works in C (narrator: "in fact, that is not how it works in C".) It just goes to show that there are fanboys everywhere who will irrationally defend everything their favourite company does.

    And yeah, I've seen lots of date/time/timezone struggles in both established tech companies and startups.