• Replies 40 replies
  • Subscribers 23 subscribers
  • Views 7464 views
  • Users 0 members are here
Options
Related

TimeZoneOffset Question

DaveBrillhart
over 5 years ago

There are situations I've discovered where a Garmin device's Activity Elapsed Time is wrong. Seems to be a weird bug under some corner cases that involve hitting the lap button when stopped, or putting the activity to sleep then resuming it.

The more consistently accurate way to get an activity's elapsed time is to grab the difference between the current time and the start time.

TWO ISSUES with this:

1. activity spans the standard -vs- daylight savings time shift. I'm guessing the start time remains fixed, and the current time can shift +/- an hour.

2. activity crossing a timezone. Again, guessing the start time stays fixed in the starting TZ, and the current time shifts +/- an hour.

There is a timezoneoffset() function returned in seconds. anyone know if this function adjusts continuously across a particular timezone - shifting a few seconds every mile traveled east or west? or just at the TZ boundaries?

I think I'll just go with the system elapsed time and not try to code a complex work-around for a bug.

  • over 5 years ago

    I don't have an answer, but have also have asked for clarification on the whole TZ thing.

    It is far too important to be left to dev's to reverse engineer from their experience.

  • over 5 years ago

    -

    Internally, the device stores UTC time, and everything related to the activity elapsed time should be calculated using the UTC start time and the UTC end time. Since there is no time zone to consider for UTC time, I'd expect the result to be unaffected by a time zone change whether it be due to a change in time zone due to position changes, or a change in offset due to entering or leaving daylight saving time.

    It sounds like you are seeing some sort of issue, but don't really have steps that we can use to reproduce it on our end. As you can imagine, having a procedure to reproduce something like this would be very helpful.

    If you were going to try and implement a workaround, you'd want to deal completely in UTC time as well. You should be able to get the current Moment from Time.now() and subtract the info.startTime to get a Duration. Since a Moment stores a UTC timestamp, it should not be affected by position on the globe or any time zone setting. The Duration would be the number of seconds that the elapsed since the activity was started. You should not need any time zone compensation because a Duration is time zone independent.

    As for your question about the ClockTime.timeZoneOffset field, it is the time zone offset. I'm not certain what inputs are required for a device to recognize that the time zone has changed (some devices get time zone information from the phone, some get it from positioning data, and some could get it from both... i don't know how frequently these updates happen or what other inputs are required).

  • over 5 years ago in reply to Alan.raceQs
    Alan.raceQs said:
    but have also have asked for clarification on the whole TZ thing.

    -

    What else do you want to know?

  • over 5 years ago in reply to Travis.ConnectIQ

    I guess I'm looking to find a complete specification of the Time::Gregorian API in one place. The current specification does not explain that it represents the time as local time, based on an internal time offset, and thus misses the opportunity to explain how that time offset is determined.

    It might appear to be quibbling, but ClockTime.timeZoneOffset is not the time zone offset (based on the Geo-political standards), but the time offset from UTC, which by default is the Time Zone, but which the user can manipulate with Settings/System/Time Auto -> Manual.

  • over 5 years ago in reply to Alan.raceQs

    The offset is from the timezone map file that gets sent to the watch occasionally.  There was just an update to it in the last week or so.  Using your GPS location, it determines your TZ offset.

  • over 5 years ago in reply to jim_m_58

    @jim_m_58, so in general, at least in the USA, as it is in seconds... it'll be 0, or +/-3600 or +/-7200, etc?

  • over 5 years ago in reply to jim_m_58

    But how do you know this stuff? It doesn't appear to be in the dev's domain. 

  • over 5 years ago in reply to DaveBrillhart

    That is different between the sim and a real device if I recall.  It's been a while (maybe the CIQ 1.x days) but on one you see an offset, and on the other the time is just shifted by the proper amount.  But maybe that's just for DST offset.

  • over 5 years ago in reply to Alan.raceQs

    It's come up a whole bunch in the devices specific forums.  There's posts about it every time that DST starts and stops.

  • over 5 years ago in reply to DaveBrillhart

     Yes, I have now played with it a bit and it displays in whole seconds, so here (UTC+11) it's 39600.

    But interestingly, if I change my watch to Manual time and then increase the time by 1 hour and a few seconds, it goes negative as shown in the top number below (I did a quick hack of my app) and the timestamps on files show yesterday's date: