Is this a timestamp?

[NewnOT]

I'm not sure where to post this, but here goes:

I'm trying to understand how a binary file (.DAT) generally works. I'm using a hex editor do this. I understand most of the file, however I'm stuck with this timestamp problem. I'm 100% sure that a part of this hex is the actual timestamp:

e1 27 17 6f e6 69 c0 00 e1 27 18 65 10 84 ef

On screen, it outputs: 9/4/2009 5:22

Note: it's DD/MM/YYYY formatted.

I've tried conversions (hex->decimal->timestamp) but no luck so far.. none of the results match the one that I've just posted above.

Any idea? Do I need to swap certain bytes or...? Or are we 100% sure that this is the actual timestamp?

Thanks in advance.

[laserlight]

On screen, it outputs: 9/4/2009 5:22

Note: it's DD/MM/YYYY formatted.

That might not actually matter, e.g., it could be a Unix timestamp which is then formatted in that format.

What is the program that uses this particular binary format? You may have better luck searching online for information concerning the format.

[whiteflags]

I'm trying to understand how a binary file (.DAT) generally works.

Well DAT is just an octet stream. Any particular program is allowed to use this extension for any purpose. You'll have to be content with knowing only the DAT files of the programs you care about.

[NewnOT]

Well, I'm not sure which program does that, etc, because the file is located and conducted on Playstation 3.

Let me re-post the timestamp and another one for comparison:


1st timestamp :

0x2d10: 00 00 00 32 00 00 00 01 00 01 10 00 00 00 00 00
0x2d20: 00 e1 27 17 6f e6 69 c0 00 e1 27 18 65 10 84 ef
0x2d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The string (0x2d2x) outputs 9/4/2009 5:22.

2nd timestamp:

0x2B60: 00 00 00 2f 00 00 00 01 00 01 10 00 00 00 00 00
0x2B70: 00 e1 2b 9e df 79 66 80 00 e1 2b 9f db d9 7b 6e
0x2B80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The string (0x2b7x) outputs 7/4/2009 22:02.

Now, I'll compare these strings:

00 e1 27 17 6f e6 69 c0 00 e1 27 18 65 10 84 ef
00 e1 2b 9e df 79 66 80 00 e1 2b 9f db d9 7b 6e

Yep... all the other timestamps are the same. (e.g. 00 e1).
hmmm...

[NewnOT]

Ok, looks like there are two timestamps (each 8 bytes) in

00 e1 27 17 6f e6 69 c0 00 e1 27 18 65 10 84 ef

One is 00 e1 27 17 6f e6 69 c0 and another one 00 e1 27 18 65 10 84 ef - Both in the same string.

I convert 00 e1 27 17 6f e6 69 c0 to 63,374,851,375,000,000 in decimal. Does that look like milliseconds to you?

I don't think this huge number can bypass the Jan 1 Year 1970 format :/

The only converters I know use the Jan 1 Year 1970 format.

Is there such a converter that uses the Jan 1 Year 1 format?

I just want to convert it to readable date / time (timestamp).

Anybody wanna help me out? Thanks a lot...

[Subsonics]

You don't know if this is a UNIX time stamp do you? But, it might be related to the 32 bit time_t problem, to which several suggested solutions have been proposed, for example (from wikipedia):

"Alternative proposals have been made (some of which are in use) including storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed-64 bit integer, providing a minimum of 300,000 years range."

[Mario F.]

I don't think this huge number can bypass the Jan 1 Year 1970 format

Oh, it definitely does, It's roughly equivalent to 2 million years, if we assumed it was miliseconds.

Anybody wanna help me out? Thanks a lot...

It's not possible to easily do that without further information. As Whiteflags told you, a dat file format is completely implementation defined.

The type of analysis you are trying to do can however be easily done if you inspect a much larger number of samples and look for those with minimal differences.

You don't know if this is a UNIX time stamp do you?

It was my thought to initially. But that wouldn't go well with the examples he gives in post #4. We'd expect the high-order bytes to remain unchanged.

[NewnOT]

But if it was a UNIX time stamp, it would be based on the Jan 1st of Year 1970 format, right?

How would I do this... any good example? Hmm... so it's impossible for web services to convert such huge numbers?

Oh, it definitely does, It's roughly equivalent to 2 million years, if we assumed it was miliseconds.

But the miliseconds represent YYYY MMD:SS

[Mario F.]

But the miliseconds represent YYYY MMD:SS

Yes and in order for that large number to represent the timestamp "9/4/2009 5:22", the starting date would have to be placed 2 million years in the past.

The following exercise is spurious because I'm pretty sure your binary sequence doesn't represent an epoch based timestamp, but (assuming miliseconds):

63,374,851,375,000,000 / 1000 = 63,374,851,375,000 seconds
63,374,851,375,000 / 60 = 1,056,247,522,916 minutes
1,056,247,522,916 / 60 = 17,604,125,381 hours
17,604,125,381 / 24 = 733,505,224 days
733,505,224 / 365 = 2,009,603 years

[Salem]

When you quote times at us, use an unambiguous format. I can't tell whether your two examples are two DAYS apart or two MONTHS apart.



1st timestamp :
0x2d20: 00 e1 27 17 6f e6 69 c0 00 e1 27 18 65 10 84 ef
The string (0x2d2x) outputs 9/4/2009 5:22.

2nd timestamp:
0x2B70: 00 e1 2b 9e df 79 66 80 00 e1 2b 9f db d9 7b 6e
The string (0x2b7x) outputs 7/4/2009 22:02.

If you're assuming this is some 8-byte counter (nanoseconds since ? for example), then why does it appear to be counting DOWN when the date increases.

Some more examples, say
1 second apart
1 minute apart
1 hour apart
would be a bonus.

The key is having lots of data samples to compare.

[NewnOT]

My bad, guys. It's not milliseconds, it's microseconds.

Okay, I'll put more timestamps:

00 E1 23 59 C2 13 3D C0
Outputs: 20/2/2009 14:49
Decimal: 63370738175000000

00 E1 23 5A 93 68 1B C0
Outputs: 20/2/2009 15:48
Decimal: 63370741687000000

00 E1 23 5B B8 01 81 00
Outputs: 20/2/2009 17:09
Decimal: 63370746596000000

00 E1 27 12 51 F8 01 80
Outputs: 8/4/2009 23:16
Decimal: 63374829398000000

00 E1 27 16 92 F2 15 00
Outputs: 9/4/2009 4:21
Decimal: 63374847668000000

I've tried a converter Tool (from microseconds to year) using a 64 bit integer, and got a correct result which is 2009. However, I can't find any converter that does the same but from microseconds to timestamp (YYYY MM DD XX:XX:XX) and vice versa.

Thanks again...

[nonoob]

It looks like your timestamp represents the number of microseconds from year 0.
This is unusual... but can be compensated for.

I'll go through the first example you gave:
00 E1 23 59 C2 13 3D C0 in base 10 is 63370738175000000
Chop off the last 6 digits (divide by a million) to get whole seconds.

63370738175

Subtract magic number 62135596800

Result: 1235141375

If you use this on-line timestamp converter below, the time will match yours: Fri, 20 Feb 2009 14:49:35 UTC
http://www.onlineconversion.com/unix_time.htm