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.
