Mintoris Forum

Author Topic: GPS time  (Read 15242 times)

mjcoon

  • Sr. Member
  • ****
  • Posts: 116
GPS time
« on: Aug 01, 2013, 09:50 AM »
I know that time from GPS hardware is defined to be in "Coordinated Universal Time" (UTC), which is close to GMT. The same applies to the Android SDK GPS time function.

Thus it is not localised to any local timezone.

I was misled by Mintoris definition of GetGpsTime() as giving the answer in Universal Time Code, which I confused with UTC.

Since I am writing a program to yield GPS NMEA over Bluetooth, as if from a standalone BT GPS dongle, I want real UTC time.

I thought perhaps I could get a de-localisation offset by doing Time(1970, 1, 1, 0, 0, 0), but that does not only not give me an offset in milliseconds, it does not even give me a fixed answer: it varies around 700 or 800 or more or less‼

What is going on, and how can I get an idea of what Mintoris thinks is the localization offset?

Mike.

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: GPS time
« Reply #1 on: Aug 03, 2013, 07:08 PM »
The GetGpsTime() function returns the time from the GPS api.  It is defined as follows:

public long getTime ()
Added in API level 1
Return the UTC time of this fix, in milliseconds since January 1, 1970.

Note that the UTC time on a device is not monotonic: it can jump forwards or backwards unpredictably. So always use getElapsedRealtimeNanos() when calculating time deltas.

On the other hand, getTime() is useful for presenting a human readable time to the user, or for carefully comparing location fixes across reboot or across devices.

All locations generated by the LocationManager are guaranteed to have a valid UTC time, however remember that the system time may have changed since the location was generated.

Returns
time of fix, in milliseconds since January 1, 1970.


It might be useful to add the getElapsedRealtimeNanos(). It won't get you the UTC though. It is defined as follows:


getElapsedRealtimeNanos()

Return the time of this fix, in elapsed real-time since system boot.

This value can be reliably compared to elapsedRealtimeNanos(), to calculate the age of a fix and to compare Location fixes. This is reliable because elapsed real-time is guaranteed monotonic for each system boot and continues to increment even when the system is in deep sleep (unlike getTime().

All locations generated by the LocationManager are guaranteed to have a valid elapsed real-time.


Returns
elapsed real-time of fix, in nanoseconds since system boot.

mjcoon

  • Sr. Member
  • ****
  • Posts: 116
Re: GPS time
« Reply #2 on: Aug 03, 2013, 11:29 PM »
The GetGpsTime() function returns the time from the GPS api.  It is defined as follows:

public long getTime ()
Added in API level 1
Return the UTC time of this fix, in milliseconds since January 1, 1970.

On the other hand, getTime() is useful for presenting a human readable time to the user, or for carefully comparing location fixes across reboot or across devices.

All locations generated by the LocationManager are guaranteed to have a valid UTC time, however remember that the system time may have changed since the location was generated.

Returns
time of fix, in milliseconds since January 1, 1970.


It might be useful to add the getElapsedRealtimeNanos(). It won't get you the UTC though. It is defined as follows:

/quote]

Thanks, Chuck, for confirming that the value is verbatim from the Android API. I am sure that in the Android documentation, "UTC" has its international meaning, that is ~GMT, and does not refer the the coding.That must mean that when using the time format function on the returned value, which I find gives local time (currently day-light saving and hence not UTC/GMT) the input time value is being "interpreted" in a way that I did not want. Hence I was trying to get the assumed local offset.

I am not sure what you mean by "Note that the UTC time on a device is not monotonic: it can jump forwards or backwards unpredictably." The time in question is that of the last GPS fix; it would be strange for that to jump backwards.

… I have just looked up the Android SDK definition, and see that you repeated it verbatim‼ That doesn't mean that I understand quite what they mean, but I see that if trying to calculate how old the latest GPS fix is, using the UTC timestamp and comparing it with the (localised?) current system time is not the best way of doing it‼

Can you explain the behaviour of "Time(1970, 1, 1, 0, 0, 0)", as I described, please?

Regards, Mike.
« Last Edit: Aug 03, 2013, 11:44 PM by mjcoon »

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: GPS time
« Reply #3 on: Aug 04, 2013, 04:55 AM »
The text in yellow is quoted directly from the Android documentation.

mjcoon

  • Sr. Member
  • ****
  • Posts: 116
Re: GPS time
« Reply #4 on: Aug 04, 2013, 09:13 AM »
The text in yellow is quoted directly from the Android documentation.

Agreed, Chuck, I acknowledged that in my message.

Can you explain the behaviour of "Time(1970, 1, 1, 0, 0, 0)", as I described, please?

And how about some access to the UTC/GMT offset functions in Android SDK, as listed under the heading "TimeZone" (though I appreciate that request belongs in another sub-forum, but the topic is relevant here‼)…

Regards, Mike.

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: GPS time
« Reply #5 on: Aug 04, 2013, 08:02 PM »
I don't know why the Time(1970, 1, 1, 0, 0, 0) should ever vary, but I notice that it never varies more than one second.  It's like they are calculating backwards using a constant that is rounded to the second.

I will have to look into adding a set of commands to work with the time zone.
« Last Edit: Aug 04, 2013, 08:10 PM by Chuck »

mjcoon

  • Sr. Member
  • ****
  • Posts: 116
Re: GPS time
« Reply #6 on: Aug 04, 2013, 09:45 PM »
I don't know why the Time(1970, 1, 1, 0, 0, 0) should ever vary, but I notice that it never varies more than one second.  It's like they are calculating backwards using a constant that is rounded to the second.

I will have to look into adding a set of commands to work with the time zone.

Thanks Chuck.

Thinking further, I believe that my Time(1970, 1, 1, 0, 0, 0) does not yield the current offset because it is a winter date and there would be no daylight saving, so local time would be UTC/GMT. Instead I used TimeFormat$(Time(), "Z")  to get a string that shows the current offset ("+0100") and turned it into milliseconds to subtract from the GPS time before formatting it. That gives me a UTC/GMT value.

But of course it would be neater to get a numeric offset in the first place‼

There will still be anomalies at the time of daylight-saving switching, which a locale-free time format function would not have…

Mike.