10

I have the following hex parts and I have a strong suspicion that behind them is a date of an event:

2013.05.23  20:35:00    08014273ed2071a6800017
2013.05.23  21:45:00    08014273ed246cf0000017
2013.05.24  17:10:00    08014273ed675173000017
2013.05.25  01:10:00    08014273ed82900f000017
2013.05.25  02:15:00    08014273ed8667b3800017
2013.05.25  17:15:00    08014273edb9c78e800017
2013.05.25  19:55:00    08014273edc2ee93000017
2013.05.25  20:30:00    08014273edc52a5a000017
2013.05.29  06:25:00    08014273eede5079000017
2013.05.29  06:35:00    08014273eedeac45000017
2013.05.29  06:40:00    08014273eedf09c6800017
2013.05.30  21:40:00    08014273ef64b021800017

The first and the second are my observations of the event (I do not have an exact time for minutes and seconds), also it might be in my time zone. In the third column is hex value, which I suspect to be a presentation of this time. Currently I assume that 08 and 17 are just delimiters.

I was looking for a timestamp representation and date time, but currently with no success. Any guess what it can be?

P.S an update with some completely different dates. I will try to find also the earlier date possible. Thanks for help

2013.01.01  00:50:00    08014273bf2ba0ed000017
2012.12.15  03:25:00    08014273b9bbb8cd000017
  • 1
    Can you also provide a few totally unrelated dates? say 2012, another month (1st or June maybe?). – NirIzr Jun 1 '13 at 13:31
  • mh. shouldn't this be closed for 'too localized'? – heinrich5991 Jun 1 '13 at 21:10
  • 1
    it might be, but this would not be helpful at all. It is not just the answer I am here for, the way which led people to it might be helpful for other people. – Salvador Dali Jun 1 '13 at 21:19
11

The numbers in the third column do increase over time, which is a good start. Let's check the differences between numbers on consecutive lines, to see if the progression is linear:

#!/usr/bin/env python
import re, sys, time
lines = sys.stdin.readlines()
def parse(l): return time.mktime(map(int,l[0:6]) + [0]*3), int(l[6], 16)
stamps = [parse(re.split('[\n.: ]+',line)) for line in lines]

print lines[0][:20]
for i in xrange(1,len(stamps)):
    (t1,x1) = stamps[i]
    (t0,x0) = stamps[i-1]
    print "%s  %8d %18d %12d" % (lines[i][:20], t1-t0, x1-x0, (x1-x0)/(t1-t0))

Output:

2012.12.15  03:25:00
2013.01.01  00:50:00   1459500   1530417643520000   1048590368
2013.05.23  20:35:00  12339900  12935551254528000   1048270346
2013.05.23  21:45:00      4200      4377804800000   1042334476
2013.05.24  17:10:00     69900     73549217792000   1052206263
2013.05.25  01:10:00     28800     29955719168000   1040129137
2013.05.25  02:15:00      3900      4224712704000   1083259667
2013.05.25  17:15:00     54000     56486789120000   1046051650
2013.05.25  19:55:00      9600     10063183872000   1048248320
2013.05.25  20:30:00      2100      2455764992000   1169411900
2013.05.29  06:25:00    294900    309126496256000   1048241764
2013.05.29  06:35:00       600       394264576000    657107626
2013.05.29  06:40:00       300       401604608000   1338682026
2013.05.30  21:40:00    140400    146949537792000   1046649129

The progression is indeed mostly linear, with the most extreme rates corresponding to the shortest intervals where the uncertainty is comparatively large. There's no marked jump on a day or month or year change, so the number is probably directly a number of units of time and not year-month-day-hour-minute-second packed in columns.

The rate is close to nanoseconds, but in fact closer to 1048 million ticks per second. It's quite possible that some of the digits on the right encode something else.

It's remarkable that all the differences are multiples of 1000. Let's print out the hexadecimal numbers in decimal:

9677354747411355314159639
9677354748941772957679639
9677354761877324212207639
9677354761881702017007639
9677354761955251234799639
9677354761985206953967639
9677354761989431666671639
9677354762045918455791639
9677354762055981639663639
9677354762058437404655639
9677354762367563900911639
9677354762367958165487639
9677354762368359770095639
9677354762515309307887639

639 isn't remarkable, and I don't see any pattern in the preceding digits either. It does seem that the data was at some point built from concatenating decimal digits, though.

Recall the intervals that were closer to 1048 million per second? Since the last 3 decimal digits are probably not part of the time, we must divide this figure by 1000. The result is remarkably close to 2^20 parts per second. So the data looks to have been assembled in decimal at some point, and in hexadecimal at some other point! Let's divide the hexadecimal numbers by 1000, but print them out in hex:

for (l,s) in zip(lines, stamps): t = (s[1] - 639) / 1000; print l[:20], s[0], hex(t)

Output:

2012.12.15  03:25:00 1355538300.0 0x20c9c4695f29de6a7efL
2013.01.01  00:50:00 1356997800.0 0x20c9c469756f1e6a7efL
2013.05.23  20:35:00 1369337700.0 0x20c9c46a31abcd6a7efL
2013.05.23  21:45:00 1369341900.0 0x20c9c46a31bc1c6a7efL
2013.05.24  17:10:00 1369411800.0 0x20c9c46a32ce1a6a7efL
2013.05.25  01:10:00 1369440600.0 0x20c9c46a333db26a7efL
2013.05.25  02:15:00 1369444500.0 0x20c9c46a334d6f6a7efL
2013.05.25  17:15:00 1369498500.0 0x20c9c46a341fdd6a7efL
2013.05.25  19:55:00 1369508100.0 0x20c9c46a34455a6a7efL
2013.05.25  20:30:00 1369510200.0 0x20c9c46a344e806a7efL
2013.05.29  06:25:00 1369805100.0 0x20c9c46a38ce166a7efL
2013.05.29  06:35:00 1369805700.0 0x20c9c46a38cf8e6a7efL
2013.05.29  06:40:00 1369806000.0 0x20c9c46a38d10d6a7efL
2013.05.30  21:40:00 1369946400.0 0x20c9c46a3af47b6a7efL

Those last 5 hexadecimal digits are constant. It's the next portion on the left that corresponds roughly to seconds since some epoch. Stripping off some digits on the left should yield the epoch, the difficulty is knowing how many hexadecimal digits to strip and how many decimal digits to strip. I'm unable to find a nice-looking epoch.

| improve this answer | |
4

Following up on Gilles answer, the first 7 hex digits (0801427) and the last 5 (00017) are not part of the timestamp. The remaining ones are the number of milliseconds from Nov 4, 2004. If you convert that to dates you get

3b9bbb8cd0  2012.12.15  03:30:30
3bf2ba0ed0  2013.01.01  00:55:50
3ed2071a68  2013.05.23  19:40:53
3ed246cf00  2013.05.23  20:50:28
3ed6751730  2013.05.24  16:19:30
3ed82900f0  2013.05.25  00:15:38
3ed8667b38  2013.05.25  01:22:47
3edb9c78e8  2013.05.25  16:20:37
3edc2ee930  2013.05.25  19:00:34
3edc52a5a0  2013.05.25  19:39:36
3eede50790  2013.05.29  05:33:02
3eedeac450  2013.05.29  05:39:18
3eedf09c68  2013.05.29  05:45:41
3ef64b0218  2013.05.30  20:41:23

The time for May or off by one hour. That could be daylight saving time.

I have no idea why that particular epoch. Could be the release date of whatever is generating the timestamps.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.