iOS Need Help converting non-integer Epoch Time

Hello, I run into an Epoch Time value that contains five decimal digits besides it's standard integer number.

I already know how to convert integer epoch values, but I'm having a hard time getting a precise conversion of epoch time with decimal digits.

Here's an example Epoch Time value I found in Consolidated.db inside the CellLocation Table, TimeStamp field :

311660150.444390

I know that 311660150 is equal to 2010/11/18 @ 04:15:49
(I would assume it's the GMT as usual).
By comparing with previous entries and measuring the GPS location differences of each record on the table, I'm positively sure the above converted time is not accurate.


Now, how do I add the decimal portion ( 0.444390 ) to get the precise time?

Thanks in advance.

ulbador said:

I'm not sure where you got that epoch time from...



311660150 == Sat, 17 Nov 1979 04:15:50 GMT

Usually, if you have a unix time formatted like that it's:

1294865421.0137 == 2011-01-12 14:51:04 CST


Everything in front of the decimal is everything up to the seconds. Everything after the decimal is usually microseconds and can generally just be truncated.

Unless you are somehow using an epoch that isn't the standard 1970 one...

Click to expand...

Sorry I forgot to mention. That's a Cocoa Epoch Time. To convert to Unix Epoch, you just have to add 978393599. I have confirmed this formula to be accurate.

The problem I'm having is with the decimal digits. I don't believe these represent microseconds, as comparing previous location records on that sqlite3 table show that a considerable GPS position difference between readings.

balamw said:

That's very odd, 'cause that seems to put time 0 at midnight between 1/1/2001 and 1/2/2001.

What's the source of these times? Is it the GPS module? I thought that had zero time sometime in 1980, with a rollover that occurred sometime around mid 1999.

If this is a standard Cocoa Time format there should be a built in function to parse/convert it.

EDIT: are you absolutely sure about your offset? It seems to me that it is off by a day from what is suggested by the documentation of NSDate
http://developer.apple.com/library/...Classes/NSDate_Class/Reference/Reference.html


I get:

Code:

$ date -j -f "%a %b %d %T %Z %Y" "Wed Jan 1 0:0:0 GMT 2001" "+%s"
978307200
$ date -j -f "%a %b %d %T %Z %Y" "Wed Jan 1 23:59:59 GMT 2001" "+%s"
978393599

EDIT 2: Look at "A" in http://unicode.org/reports/tr35/tr35-6.html#Date_Format_Patterns this should help you see what you get in milliseconds and you should be able to work back from that.

EDIT 3: See the docs for NSDate:

Code:

NSTimeIntervalSince1970
NSDate provides a constant that specifies the number of seconds from 1 January 1970 to the reference date, 1 January 2001.

#define NSTimeIntervalSince1970  [B][B]978307200.0[/B][/B]
Constants
NSTimeIntervalSince1970
The number of seconds from 1 January 1970 to the reference date, 1 January 2001.
Available in Mac OS X v10.0 and later.
Declared in NSDate.h.
Discussion
1 January 1970 is the epoch (or starting point) for Unix time.

Declared In
NSDate.h

B

Click to expand...

You are correct, there was an error in the offset which I have corrected last night.

I suspect the decimals play a role in the calculation, as the logs show the same exact time for reading A and then for reading B which shows a location of about a mile away. This was the only TimeStamp field in an iPhone SQLite3 DB that contains decimal digits.

In the iPhone logs, some timestamps use a Unix Epoch, others use the Cocoa Epoch, and now what seems to be a Cocoa Epoch with decimal digits. What a mess!

Thanks for your help. I'll research your links above and report back.

balamw said:

Given Amazing Iceman's redefinition of the offset from 1970-2001 I think he's rolling his own and not using any of the calls provided or reading the docs and trying to reverse engineer stuff unnecessarily.

All the docs seem to imply that it's just fractional seconds. So 311660150.444390 would be 444390 microseconds past 311660150 (Or 444.390 milliseconds). The "A" formatter seems to be the only place I could find any precision beyond seconds in the docs quickly.

B

Click to expand...

You are right about that. I'm doing forensic analysis by retrieving data from a backup, not programming. So I have to come up with the exact formula to get any meaningful information. I'll apply your suggestions and see if the dates start to make some sense. At least I have a reference point for the last time in the log.

balamw said:

I would suspect the GPS coordinates then. The integer part definitely allows you to get whole seconds. If you move a mile in a second, you are basically traveling 3,600 miles per hour. That's about 5 times the speed of sound.

Unless of course you are tracking jets/missiles?


Regardless, you are best served by reading the docs and using the provided calls where possible. Stuff the values you get from the db in the right data structure and use the provided calls. Roll your own only when you have to.

e.g. the offset between 1970 and "reference time" is documented, using the constant NSTimeIntervalSince1970 instead of a number pulled from thin air will help you code stay readable and correct.

B

Click to expand...

LOL.
Thanks. I'll keep researching. I was able to get accurate timestamp using my formula for Cocoa Epochs.