Timer in Data field

I am trying to make a timer data field for official races that tracks your chip time, this means that it will start the timer not when the activity starts but instead when a push notification is sent to the watch (notification of passing the starting line) and stop it when another notification is sent (notification of passing the finish line). The sending information has already been handled but I am having difficulty displaying a correctly incrementing timer. The main issue is that the timer class cannot be used in a datafield. I tried to make it with a display that updated every second but it wasn't smooth and incremented slow, causing it to fall behind where it should be. Another roadblock is that there is a chance that the starting time will have an issue meaning that a runner's timer is incorrect and I need to have the functionality to send their correct time so that the timer can be set to that and carry on as normal 

  • Just watch for errors introduced due to timezone crossings (yes, that would be extremely rare but something to consider), and the time skew that can occur once a GPS lock occurs and the device updates it's internal time to GPS time.

  • There is a known issue. Well, it is known and demonstrated and reported by me, but low priority and likely won't ever be fixed. ActivityInfo...elaspedTime should be the clock time since Activity Start until it ends. But this metric drifts from what it should be if you hit the LAP button when auto-paused (not moving) say at an intersection. elapsedTime should never stop counting as long as the Activity is active, until you hit SAVE. But it loses a few seconds under those conditions. Not a big deal at all. But I now use (CURRENT TIME - START TIME) for my internal CIQ calculations for Elapsed Time and that fixes this strange little bug.

  • All of what you’re saying is why I would use the system uptime (Timer.getTimer()) as a reference clock. I would only use the time of day / unix time for time sync.

  • Also, Time.now() and Time.getCurrentTime() -- which return a Moment, which is internally represented as the number of seconds since the Unix epoch (UTC) -- shouldn't have any problems with time zones as long as you never try to convert them to local time.