• Replies 19 replies
  • Subscribers 18 subscribers
  • Views 5619 views
  • Users 0 members are here
Options
Related

Problem with time when set to manual

Alan.raceQs
I'm not sure if it's the way a "Moment" is constructed, or the way "Gregorian.Info" converts it to a readable date, but it appears that a Unix timestamp value will convert to different times depending on the system time of the watch. (And I'm taking into account timezone differences.)

In my example, I am using an arbitrary Unix timestamp (value of 1494290000) which is equivalent to May 9 2017 00:33:20 UTC.
In my demo, I create a Gregorian.Info object from var timestruct = Gregorian.info(new Time.Moment(1494290000 ), Time.FORMAT_SHORT);
and then display it using the year, month, day, hour, min and sec functions.
formattedReportTime = timestruct.year
+"-"+ timestruct.month.format("%02u")
+"-"+ timestruct.day.format("%02u")
+"\n"+ timestruct.hour.format("%02u")
+ ":" + timestruct.min.format("%02u")
+ ":" + timestruct.sec.format("%02u");

Under normal circumstances, it correctly displays
May 9 2017 10:33:20 (As I'm in Sydney, UTC=10 )
However,if I manually set my watch 30 mins slow, (change time settings from auto to manual and alter the minutes) it displays
May 9 2017 10:03:20 or 30 minutes earlier.
By messing with the time, I have found that the error in the conversion matches the difference between the watch time and the "true" time, which I believe it gets from the GPS.

I can only demonstrate this on a watch (VA-HR) as it's not possible to mess with the time settings in the emulator.

I'm posting this here, rather than report it as a bug in case it turns out I'm missing something in my logic.
  • But wait… there's more.

    I stumbled across this line of study when I suspected that Location.Info.when wasn't giving me the real GPS timestamp.

    As we know, the date part of the timestamp is 20 years + 1 day slow (shows 1997-05-10 when it's really 2017-05-09) but I had come to suspect the time part as well, so I did some checking and found that if I change the time to manual and set the clock ½ hr slow, then the time reported in Location.Info.when is also ½ hr slow.

    So, contrary to what the doco on #when says, Location.Info.when is NOT the "GPS time stamp of fix".

    I suspect that this is closely connected with the earlier post, but have no idea why.
  • Internally, the device keeps track of the current UTC time. This is the 'system time'. When you set the time using the device settings pages, you're telling the device the offset to apply to get from UTC time to your local time. When you call {{Gregorian.info()}}, you are asking the VM to convert the UTC timestamp (1494290000) to your local time, and internally the time zone offset you've supplied is used to do this calculation.

    As far as I can tell, everything is working exactly as it should be.

    I haven't looked at the Location.Info.when field, but if you are outputting the date/time as local time, you can expect that the result will be skewed by any offset you have manually applied in the device settings pages.

    Travis
  • Yes, I've now reconciled the behaviour of Gregorian.info, and see that it makes good sense.

    My post #2 was specifically about Location.info.when, and no, I don't output as local time, I work with UTC.
    WhenLocation.info is reporting from the GPS, I really expected it to be providing the GPS timestamp relating to the lat/lon/alt position to provide the best possible answer to where was I at that time, especially when the device is in motion.
    I'm retrieving the coordinates with:
    Position.enableLocationEvents(Position.LOCATION_CONTINUOUS, method(:GPSData));
    then retrieving what I hoped to be the raw GPS timestamp into a local variable with:
    function GPSData(positionInfo){
    timeSecs = positionInfo.when.value();


    This is the value I was surprised to see was based on the system time that the callback was received, not the GPS time related to the lat/lon/alt
  • The GPS timestamp that we provide (the when field of the returned Position.Info) is a Time.Moment. Internally, it stores the number of seconds since the UNIX epoch (1970-01-01T00:00:00 UTC). This is mentioned in the documentation for the class.

    I would expect that if you displayed timeSecs in an app, you would see a timestamp value that roughly coincided with the UTC timestamp displayed here:

    https://www.epochconverter.com/clock

    The value should be consistent regardless of what timezone you are in or what manual time setting you are using in the device settings.

    I'll take a few minutes to verify on a device today, but I'm pretty sure everything is behaving exactly as I'd expect.
  • Nope:
    I'm getting 921184556 which converts to

    1999-03-11T20:35:54+00:00 in ISO 8601

  • I've found the problem, but it is unrelated to the local time issue you mentioned previously. The GPS time system uses a 1024 week window, and we were interpreting the week number without considering that cycles may have occurred. This could cause dates to be off by 7168 days.
  • Well, that's a huge breakthrough!
    I was doing some work on the differences but didn't convert the seconds to days, so missed the constant 7168.

    And yes, sorry if my suggesting the two issues might be connected put you off the scent: they were just two of the three problems I had with the timestamp, the third being the 5% slow which is now fixed but sadly, not yet released on VA-HR.

    But while you're looking at this stuff, it would be great if you could get Location.Info.when to actually deliver the GPS time stamp of fix, without any modulation with clock offsets.

  • it would be great if you could get Location.Info.when to actually deliver the GPS time stamp of fix, without any modulation with clock offsets.

    It is documented to return a Time.Moment, and Time.Moment is documented to store the number of seconds since the UNIX epoch. Unless there was a *really* good reason, we would not make a change that deviated from the documented behavior.
  • I don't have any issue with it being a Time.Moment.

    My issue is that I'm expecting "The GPS time stamp of the obtained Location fix." (as per the spec) but it's returning the system time which can be corrupted by a clock offset, generated intentionally or accidentally by the user twiddling the time source (Manual or Automatic).
  • You are confusing me... A proper solution will produce a Time.Moment with exactly the same value stored internally for a given instant without regard to the where the device is or what the settings are. Any solution that didn't do this would be incorrect.

    I've re-read your comments above several times, and this sentence really jumps out at me...

    When Location.info is reporting from the GPS, I really expected it to be providing the GPS timestamp relating to the lat/lon/alt position


    It seems that you are expecting the time value to be *different* based on where you are on the globe, but that is not how it works.