I have an existing software, with no source and possible editing. It contains a grid (looks like an old DevExpress one, the software itself is created in Delphi 7). Grid content is stored in the memory, which I have to read and modify externally.
I've successfully decoded the structure, except for date+time fields. It's stored in 8 bytes. I've checked all common structures, such as TDateTime
as a double variable, TTimeStamp
as two integers, TFileTime
, Windows OLE, MySQL timestamp, other timestamps, but found nothing closely relative.
I can input any data and check the result in the table, so I am sure data is correct.
I've provided examples of data times in bytes and the result in grid. Can test any other, if it helps.
00 00 00 00 00 00 00 43 - 04.03.17840 11:03:41
00 00 00 00 00 00 00 41 - "0.131072 is not a valid timestamp"
00 00 00 00 00 00 00 42 - 09.04.001 10:05:34
00 00 00 00 00 00 67 42 - 15.01.0026 16:33:02
00 00 00 00 00 00 CB 42 - 22.06.1882 18:24:59
00 00 00 00 00 00 CC 42 - 28.02.1952 10:12:35
00 00 00 00 00 E4 CC 42 - 22.03.2014 07:24:02
00 00 00 00 00 E5 CC 42 - 29.06.2014 17:29:37
00 00 00 00 3D E5 CC 42 - 23.07.2014 10:03:17
00 95 1E 7E 3D E5 CC 42 - 23.07.2014 14:38:48
00 87 F9 7C 3D E5 CC 42 - 23.07.2014 14:36:18
00 4C 99 57 38 E5 CC 42 - 21.07.2014 14:38:26
80 55 0C 2E 3E E4 CC 42 - 15.04.2014 10:57:32
UPDATE 1: Weird differnce in the years mentioned in the comment lead to a discovery, that date is not strictly linear to the elder bytes. I've tested this:
00 00 00 00 00 00 CA 42 - 16.10.1812
00 00 00 00 00 00 CB 42 - 22.06.1882
00 00 00 00 00 00 CC 42 - 28.02.1952
The difference between values is ~70 years (~25452 days)
And now this:
00 00 00 00 00 00 BA 42 - 23.11.0906
00 00 00 00 00 00 BB 42 - 26.09.0941
00 00 00 00 00 00 BC 42 - 30.07.0976
The difference is actually ~35 years (~12726 days)
To sum it up, here's the breakdown:
00 00 00 00 00 00 BD 42 - 04.06.1011
00 00 00 00 00 00 BE 42 - 06.04.1046 (+35 years)
00 00 00 00 00 00 BF 42 - 07.02.1081 (+35 years)
...
00 00 00 00 00 00 C0 42 - 13.12.1115 (+35 years)
00 00 00 00 00 00 C1 42 - 19.08.1185 (+70 years)
00 00 00 00 00 00 C2 42 - 25.04.1255 (+70 years)
...
00 00 00 00 00 00 C8 42 - 02.06.1673 (+70 years)
00 00 00 00 00 00 C9 42 - 08.02.1743 (+70 years)
00 00 00 00 00 00 CA 42 - 16.10.1812 (+70 years)
...
00 00 00 00 00 00 CE 42 - 11.07.2091 (+70 years)
00 00 00 00 00 00 CF 42 - 18.03.2161 (+70 years)
...
00 00 00 00 00 00 D0 42 - 24.11.2230 (+70 years)
00 00 00 00 00 00 D1 42 - 07.04.2370 (+140 years)
00 00 00 00 00 00 D2 42 - 19.08.2509 (+140 years)
So it looks like the elder bits is rather some coeff, not the date directly
I've tested lesser bits, they seem to behave more logically:
00 00 00 00 00 00 CC 42 - 28.02.1952
00 00 00 00 00 01 CC 42 - 06.06.1952
00 00 00 00 00 02 CC 42 - 14.09.1952
~100 days
00 00 00 00 00 CC CC 42 - 09.09.2007
00 00 00 00 00 CD CC 42 - 17.12.2007
00 00 00 00 00 CE CC 42 - 26.03.2008
~100 days
00 00 00 00 00 FC CC 42 - 02.10.2020
00 00 00 00 00 FD CC 42 - 09.01.2021
00 00 00 00 00 FE CC 42 - 19.04.2021
~100 days
And for the fourth byte:
00 00 00 00 00 CC CC 42 - 09.09.2007 05:10:12
00 00 00 00 01 CC CC 42 - 09.09.2007 14:29:26
00 00 00 00 02 CC CC 42 - 09.09.2007 23:48:26
~9 hours
00 00 00 00 CC CC CC 42 - 27.11.2007 10:35:16
00 00 00 00 CD CC CC 42 - 27.11.2007 19:54:30
00 00 00 00 CE CC CC 42 - 28.11.2007 05:13:45
~9 hours
For the question on the breakdown of +1m, +1h, etc. It's much harder to test, since I cannot input the random date and get its code, only the opposite. But I can add the value manually, and test its internal structure. Here's what I managed to grab today:
00 90 D2 80 4A E5 CC 42 - 28.07.2014 15:54:50
00 E3 D4 80 4A E5 CC 42 - 28.07.2014 15:54:51
80 5D 48 81 4A E5 CC 42 - 28.07.2014 15:55:50
80 5A 4B 81 4A E5 CC 42 - 28.07.2014 15:55:51
80 D4 49 9C 4A E5 CC 42 - 28.07.2014 16:54:50
00 8C 4C 9C 4A E5 CC 42 - 28.07.2014 16:54:51