PDA

View Full Version : Need Help converting non-integer Epoch Time




Amazing Iceman
Jan 12, 2011, 02:20 PM
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. :D



ulbador
Jan 12, 2011, 02:52 PM
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...

Amazing Iceman
Jan 12, 2011, 05:22 PM
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...

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
Jan 12, 2011, 06:05 PM
To convert to Unix Epoch, you just have to add 978393599. I have confirmed this formula to be accurate.


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/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSDate_Class/Reference/Reference.html

The sole primitive method of NSDate, timeIntervalSinceReferenceDate, provides the basis for all the other methods in the NSDate interface. This method returns a time value relative to an absolute reference date—the first instant of 1 January 2001, GMT.

I get:$ 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:

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

#define NSTimeIntervalSince1970 978307200.0
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

ulbador
Jan 12, 2011, 09:21 PM
The sole primitive method of NSDate, timeIntervalSinceReferenceDate, provides the basis for all the other methods in the NSDate interface. This method returns a time value relative to an absolute reference date—the first instant of 1 January 2001, GMT.

So he was just using the wrong call then? That would seem to make sense. I honestly cannot see (not to say they wouldn't do it), Apple trying to redefine the epoch. So I amend my first response by saying I have no idea what the number you have represents, so the decimal points may not represent microseconds.

balamw
Jan 12, 2011, 09:44 PM
So he was just using the wrong call then?

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

Amazing Iceman
Jan 13, 2011, 08:45 AM
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/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSDate_Class/Reference/Reference.html


I get:$ 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:

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

#define NSTimeIntervalSince1970 978307200.0
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

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.

Amazing Iceman
Jan 13, 2011, 08:50 AM
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

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
Jan 13, 2011, 08:57 AM
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.

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? :p

You are right about that. I'm doing forensic analysis by retrieving data from a backup, not programming.
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

Amazing Iceman
Jan 13, 2011, 01:31 PM
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? :p


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

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

balamw
Jan 13, 2011, 02:17 PM
I was able to get accurate timestamp using my formula for Cocoa Epochs.

How did you interpret the decimal portion in the end?

B