What is the date and time format?

Question

I have a DateTime structure for the old data format, to which I do not have access to any specifications. There is a field that indicates the date and time of the data, but this is not in any format that I recognize. It seems to be stored as a 32-bit integer, which increases by 20 every day. Has anyone ever come across something like this?

EDIT:

Example: 1088631936 DEC = 80 34 E3 40 00 00 00 00 HEX = 07/07/2007

EDIT:

First of all, sorry for the delay. I was hoping to do something on the weekend, but couldn't.

Secondly, this date format is weirder than I originally thought. Apparently, this is a kind of exponential or logarithmic method, since dates do not change with increasing speed.

Thirdly, the non-existent application that I have for interpreting these values ​​shows only part of the date, so I do not know what part of the time.

Examples of data: (Hex values ​​are large, dates are mm / dd / yyyy)

0x40000000 = 01/01/1900
0x40010000 = 01/01/1900
0x40020000 = 01/01/1900
0x40030000 = 01/01/1900
0x40040000 = 01/01/1900
0x40050000 = 01/01/1900
0x40060000 = 01/01/1900
0x40070000 = 01/01/1900
0x40080000 = 01/02/1900
0x40090000 = 01/02/1900
0x400A0000 = 01/02/1900
0x400B0000 = 01/02/1900
0x400C0000 = 01/02/1900
0x400D0000 = 01/02/1900
0x400E0000 = 01/02/1900
0x400F0000 = 01/02/1900
0x40100000 = 01/03/1900
0x40110000 = 01/03/1900
0x40120000 = 01/03/1900
0x40130000 = 01/03/1900
0x40140000 = 01/04/1900
0x40150000 = 01/04/1900
0x40160000 = 01/04/1900
0x40170000 = 01/04/1900
0x40180000 = 01/05/1900
0x40190000 = 01/05/1900
0x401A0000 = 01/05/1900
0x401B0000 = 01/05/1900
0x401C0000 = 01/06/1900
0x401D0000 = 01/06/1900
0x401E0000 = 01/06/1900
0x401F0000 = 01/06/1900
0x40200000 = 01/07/1900
0x40210000 = 01/07/1900
0x40220000 = 01/08/1900
0x40230000 = 01/08/1900
....
0x40800000 = 05.26.1901
0x40810000 = 06/27/1901
0x40820000 = 07.29.1901
....
0x40D00000 = 11/08/1944
0x40D10000 = 08/29/1947

EDIT: I finally figured it out, but since I have already given up points for generosity, I will postpone the decision if someone wants to take a picture.

By the way, there is no time component for this, it is purely for storing dates.

Answer 1

This is not an integer, this is a 32-bit floating point number. I have not quite developed a format yet, this is not IEEE.

Edit: succeeded. A 1-bit character, an 11-bit metric with an offset of 0x3ff, and a 20-bit mantissa with an implied bit to the left. In C, assuming only positive numbers:

double offset = pow(2, (i >> 20) - 0x3ff) * (((i & 0xfffff) + 0x100000) / (double) 0x100000); 

This gives 0x40000000 = 2.0, so the start date should be 12/30/1899.

Edit again: since you were so kind as to accept my answer, and you seem to be worried about speed, I thought I would clarify this a bit. You do not need the fractional part of a real number, so we can convert directly to an integer using only bitwise operations. In Python this time, complete with test results. I have included some intermediate values ​​for better readability. In addition to limiting negative numbers, this version may have problems when the figure is over 19, but this should keep you in good condition until 3335.

 >>> def IntFromReal32(i): exponent = (i >> 20) - 0x3ff mantissa = (i & 0xfffff) + 0x100000 return mantissa >> (20 - exponent) >>> testdata = range(0x40000000,0x40240000,0x10000) + range(0x40800000,0x40830000,0x10000) + [1088631936] >>> from datetime import date,timedelta >>> for i in testdata: print "0x%08x" % i, date(1899,12,30) + timedelta(IntFromReal32(i)) 0x40000000 1900-01-01 0x40010000 1900-01-01 0x40020000 1900-01-01 0x40030000 1900-01-01 0x40040000 1900-01-01 0x40050000 1900-01-01 0x40060000 1900-01-01 0x40070000 1900-01-01 0x40080000 1900-01-02 0x40090000 1900-01-02 0x400a0000 1900-01-02 0x400b0000 1900-01-02 0x400c0000 1900-01-02 0x400d0000 1900-01-02 0x400e0000 1900-01-02 0x400f0000 1900-01-02 0x40100000 1900-01-03 0x40110000 1900-01-03 0x40120000 1900-01-03 0x40130000 1900-01-03 0x40140000 1900-01-04 0x40150000 1900-01-04 0x40160000 1900-01-04 0x40170000 1900-01-04 0x40180000 1900-01-05 0x40190000 1900-01-05 0x401a0000 1900-01-05 0x401b0000 1900-01-05 0x401c0000 1900-01-06 0x401d0000 1900-01-06 0x401e0000 1900-01-06 0x401f0000 1900-01-06 0x40200000 1900-01-07 0x40210000 1900-01-07 0x40220000 1900-01-08 0x40230000 1900-01-08 0x40800000 1901-05-26 0x40810000 1901-06-27 0x40820000 1901-07-29 0x40e33480 2007-09-07 

Answer 2

Are you sure the values ​​correspond to 07/07/2007?

I ask, because 1088631936 is the number of seconds since the moment when Linux (and others) did not indicate the date: 01/01/1970 00:00:00 - 06/30/2004 21:45:36.

It seems reasonable to me to think that the value is seconds from this usual zero date.

Edit: I know that it is very possible that this is not the correct answer. This is just one approach (valid), but I think more information is needed (see Comments). Editing this (again) to put a question to the front in the hope of someone else answering it or giving ideas. Me: with justice, sport and a shared spirit: D

Answer 3

I would say vmarquez is close.

Below are the dates 2009-3-21 and 2009-3-22 as unix epochtime:

 In [8]: time.strftime("%s", (2009, 3, 21, 1, 1, 0, 0,0,0)) Out[8]: '1237590060' In [9]: time.strftime("%s", (2009, 3, 22, 1, 1, 0, 0,0,0)) Out[9]: '1237676460' 

And here they are in hexadecimal format:

 In [10]: print("%0x %0x" % (1237590060, 1237676460)) 49c4202c 49c571ac 

If you take only the first 5 digits, the growth is 21. Which view matches your format, neg?

Answer 4

Some context would be helpful. If your data file looks something, literally or at least figuratively, like this file, vmarquez for money.

http://www.slac.stanford.edu/comp/net/bandwidth-tests/eventanalysis/all_100days_sep04/node1.niit.pk

This link is the data obtained with the Affordable Range Estimation Tool (ABwE) tool - the curious element is that it actually contains this value 1088631936, as well as the context. This example

 date time abw xtr dbcap avabw avxtr avdbcap rtt timestamp 06/30/04 14:43:48 1.000 0.000 1.100 1.042 0.003 1.095 384.387 1088631828 06/30/04 14:45:36 1.100 0.000 1.100 1.051 0.003 1.096 376.408 1088631936 06/30/04 14:47:23 1.000 0.000 1.100 1.043 0.003 1.097 375.196 1088632043 

It seems to have a seven-hour bias from the estimated time value of 21:45:36. (Probably Stanford Daylight Saving.)

Answer 5

Well, you just showed us how your program uses 2 out of 8 digits, so we will have to assume that the remaining 6 are ignored (because your program can do whatever it wants with these other digits).

So, we can say that the input format is: 40mn0000 where m and n are two hexadecimal digits.

Then output: 01/01/1900 + gender ((2 ^ (m + 1) -2) + n * 2 ^ (m-3)) days

Explanation:

• In each example, note that incrementing n by 1 increases the number of days by 2 ^ (m-3).
• Note that every time n goes from F to 0, m increases.

Using these two rules and playing with numbers, you get the equation above. (Except for the floor that was added because fractional days are not displayed on the output).

I guess you could rewrite this by replacing two separate hexadecimal variables m and n with one six-digit hexadecimal number H. However, I think this will make the equation a lot uglier.