Devices Position.Info.when is in Garmin time and not UTC

o A Descriptive Title (i.e. “Simulator Freezes Launching App in Eclipse”)
Devices Position.Info.when is in Garmin time and not UTC

o The Environment:
Windows 10
Eclipse Neon.1 (4.6.1)
ConnectIQ 2.2.3
vivoactive_hr, fr630, ...

o A detailed description of the issue
The value stored in the when field of the Position.Info when running on a device appears to be in Garmin time instead of UTC time. i.e., it is 20 years behind. When running on the simulator, it is correct.

o Steps to reproduce the issue
Compile and run the test case below. If you run it in the simulator, and simulate data, you'll see current timestamp, date and time values displayed. You can verify the timestamp is correct by comparing it with what you see on http://www.unixtimestamp.com. If you build the app for a device and run it on the device, you'll see that the date/time is in 1997.

o Any applicable additional information
N/A

o A code sample that can reproduce the issue (in email only if preferred)
using Toybox.Application as App;
using Toybox.Lang as Lang;
using Toybox.Graphics as Gfx;
using Toybox.Math as Math;
using Toybox.Position as Position;
using Toybox.System as Sys;
using Toybox.Time as Time;
using Toybox.Time.Gregorian as Gregorian;
using Toybox.WatchUi as Ui;

class XView extends Ui.View
{
function initialize() {
View.initialize();
}

function onShow() {
Position.enableLocationEvents(Position.LOCATION_CONTINUOUS, self.method(:onPosition));
}

function onHide() {
Position.enableLocationEvents(Position.LOCATION_DISABLE, null);
}

hidden var _M_info;

function onPosition(info) {
_M_info = info;
Ui.requestUpdate();
}

function onUpdate(dc) {
dc.setColor(Gfx.COLOR_WHITE, Gfx.COLOR_BLACK);
dc.clear();

var font = Gfx.FONT_SMALL;
var fy = dc.getFontHeight(font);

var cx = dc.getWidth() / 2;
var cy = dc.getHeight() / 2;

var justification = Gfx.TEXT_JUSTIFY_CENTER | Gfx.TEXT_JUSTIFY_VCENTER;
var s;

if (_M_info != null && _M_info.accuracy > Position.QUALITY_LAST_KNOWN) {
cy -= fy;

s = _M_info.when.value().toString();

dc.drawText(cx, cy, font, s, justification);
cy += fy;

var info = Gregorian.info(_M_info.when, Time.FORMAT_SHORT);
s = Lang.format("$1$-$2$-$3$", [
info.year.format("%04u"),
info.month.format("%02u"),
info.day.format("%02u")
]);

dc.drawText(cx, cy, font, s, justification);
cy += fy;

s = Lang.format("$1$:$2$:$3$", [
info.hour.format("%02u"),
info.min.format("%02u"),
info.sec.format("%02u")
]);

dc.drawText(cx, cy, font, s, justification);
cy += fy;
}
else {
s = "Wait...";
dc.drawText(cx, cy, font, s, justification);
}
}
}

class XApp extends App.AppBase
{
function initialize() {
AppBase.initialize();
}

function getInitialView() {
return [ new XView() ];
}
}


Travis
  • Hey Travis,

    This one was an easy one to verify. Thanks for the catch. I've created a ticket.

    Thanks,
    -Coleman
  • I've bumped this ticket to try and get some more priority.

    Thanks,
    -Coleman
  • I stumbled on the same "bug".
    I verified (D2 Charlie FW2.30 last time I checked) the Position.Info.when data actually are GPS epoch - https://en.wikipedia.org/wiki/Global...em#Timekeeping - *non-corrected for the correct 1024-week quadrant*.
    This is not a problem "per se", provided the documentation matches the reality (it currently says the data are UTC epoch)
    Best
  • The problem is that the object type (Time.Moment) represents the offset from the UNIX time epoch in UTC. Users of the API (including other parts of the API) expect this and will generate incorrect results if the data doesn't meet the expectations.

    I am almost certain that I double-checked the devices I had at the time before posting, and my comments above indicate a 20 year offset. The Garmin epoch (1990-01-01T00:00:00Z) is exactly 20 years off of the UNIX epoch and the GPS time epoch (1980-01-06T00:00:00Z) is 10 years and 6 days off, so that is why I suggested the value was using Garmin time..

    Of course it is possible that you are seeing a device-specific behavior that is different than the device behavior that I was seeing. I haven't yet looked at the code, but I have doubts this is the case. I'm sure I'll find out soon enough.

    Travis

  • We got this addressed back in the 2.4.2 SDK release. Thanks!