Need Help converting non-integer Epoch Time

Discussion in 'iOS Programming' started by Amazing Iceman, Jan 12, 2011.

  1. macrumors 68030

    Amazing Iceman

    Joined:
    Nov 8, 2008
    Location:
    Florida, U.S.A.
    #1
    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
     
  2. macrumors 68000

    ulbador

    Joined:
    Feb 11, 2010
    #2
    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...
     
  3. thread starter macrumors 68030

    Amazing Iceman

    Joined:
    Nov 8, 2008
    Location:
    Florida, U.S.A.
    #3
    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.
     
  4. balamw, Jan 12, 2011
    Last edited: Jan 12, 2011

    Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #4
    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
     
  5. macrumors 68000

    ulbador

    Joined:
    Feb 11, 2010
    #5
    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.
     
  6. Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #6
    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
     
  7. thread starter macrumors 68030

    Amazing Iceman

    Joined:
    Nov 8, 2008
    Location:
    Florida, U.S.A.
    #7
    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.
     
  8. thread starter macrumors 68030

    Amazing Iceman

    Joined:
    Nov 8, 2008
    Location:
    Florida, U.S.A.
    #8
    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.
     
  9. balamw, Jan 13, 2011
    Last edited: Jan 13, 2011

    Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #9
    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
     
  10. thread starter macrumors 68030

    Amazing Iceman

    Joined:
    Nov 8, 2008
    Location:
    Florida, U.S.A.
    #10
    LOL.
    Thanks. I'll keep researching. I was able to get accurate timestamp using my formula for Cocoa Epochs.
     
  11. Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #11
    How did you interpret the decimal portion in the end?

    B
     

Share This Page