2

This is the sample data that the gps android device get to gps. 1389782318000 I want it to convert to local time.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
GummyBear0014
  • 105
  • 2
  • 11

2 Answers2

4

http://leapsecond.com/java/gpsclock.htm

GPS time was zero at 0h 6-Jan-1980 and since it is not perturbed by leap seconds GPS is now ahead of UTC by 16 seconds.

For updates you may need to keep an eye out based on http://en.wikipedia.org/wiki/Leap_second

Leap seconds are irregularly spaced because the Earth's rotation speed changes irregularly. Indeed the Earth's rotation is quite unpredictable in the long term, which explains why leap seconds are announced only six months in advance.

Based on this information your looking at 

double seconds = 1074895216;
int leapSecondsAdj = 16;
DateTime gpsConverted = 
    new DateTime(1980, 1, 6, 0, 0, 0, DateTimeKind.Utc)
    .AddSeconds(seconds-leapSecondsAdj);

Please note that this solution only is valid for dates after June 30, 2012 which is when the last leap second was added. For times before this you will need to create a table of leap seconds and determine the correct adjustment based on the table.

Also, could you please explain your sample time as 1389782318000 is not to the correct scale as mentioned by ichabod-clay.

UPDATE

Based on the link in your comment below it looks like this is not GPS time but UTC time in ms.

This question has been answered here and/or here and you can use the below.

double seconds = 1389782318000d/1000;
DateTime utcConverted = 
    new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc)
    .AddSeconds(seconds)
    .ToLocalTime();
Community
  • 1
  • 1
Harrison
  • 3,843
  • 7
  • 22
  • 49
  • Careful with that seconds value. 1389782318000 seconds roughly translates to about 44 thousand years. I would hazard a guess that the value is in milliseconds instead of seconds. It would make more sense at least. – Ichabod Clay Jan 28 '14 at 03:17
  • @IchabodClay. Good point. I'm not sure where the OP got that time. – Harrison Jan 28 '14 at 03:22
  • 1389782318000 i got this time in an android device. this is the link [link]http://developer.android.com/guide/topics/location/strategies.html – GummyBear0014 Jan 28 '14 at 03:35
  • @user2597863. The documentation in the link you provided is for location positioning. I did look at the ancillary specifications and it all time refers to UTC *Return the UTC time of this fix, in milliseconds since January 1, 1970.* Did you mean to ask how to convert the UTC time to LocalTime? – Harrison Jan 28 '14 at 03:57
  • why their is "d" in the last digit of number sir? – GummyBear0014 Jan 28 '14 at 04:26
  • @user2597863 it is a literal to treat the number as a double so you don't do integer division (although in this particular case - with a 000 ending - it wouldn't matter). – Harrison Jan 28 '14 at 04:32
  • When i run the result Monday, January 01, 0001 its weird this should be Wed Jan 15 2014 10:38:38 AM my base is [link]http://currentmillis.com/ – GummyBear0014 Jan 28 '14 at 04:42
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/46187/discussion-between-harrison-and-user2597863) – Harrison Jan 28 '14 at 04:45
  • @Harrison im in the chat now sir – GummyBear0014 Jan 28 '14 at 06:27
1

I came across a description of the getTime function that says this:

public long getTime () 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.

Yikes! Is that true? Even if it does indeed return a time object that includes the milliseconds value that value is TOTALLY USELESS if it "can jump forwards or backwards unpredictably".

The project that I'm working on absolutely needs an "accurate to the millisecond" time value (even if it's "milliseconds since January 1, 1970"). Without that accuracy my project is screwed!

Roger Garrett
  • 349
  • 1
  • 7
  • 13