Questions

Can anyone figure out these 6 byte 'compressed' dates?

+
0 Votes
Locked

Can anyone figure out these 6 byte 'compressed' dates?

jbwilson1120
I have opened the DBF file from ACT! 2000 (v5) in Access 2007. Among all of the contact fields are two timestamp fields that the ACT app creates. They are 6 character text fields and the manual states that they are system fields that store the create and edit times for the record. It says they are 'compressed' date fields.

Here are a few samples from the field:
CTIME
-------
!#ZF.U
!#ZF.X
!+9SP&
!+HD8,
!)9VZK

I have looked at them in a binary editor and none seem to make sense. Has anybody had experience with 6 byte timestamps like this?

Thanks,
Jeremy
+
0 Votes
Tony Hopkinson

DBf date format was 3 bytes YY MM DD started at 1900 so I say the other three are HH MM SS since midnight.

+
0 Votes
Charles Bundy

Meant the number of seconds elapsed since midnight January 1, 1970.

+
0 Votes
Charles Bundy

You sure this is an actual date and not a transaction timer?

http://support.microsoft.com/kb/44415

Reason I say this is hex values don't fall into any rational ranges for MMDDYYhhmmss...

+
0 Votes
jbwilson1120

Thanks for the quick replies. You're right. It doesn't make sense as YMDHMS. 1:1933, 2:Month=35?, 3:Day=90?

------------- DECIMAL -------------
|
[VALUE] 1 2 3 | 4 5 6
!#ZF.U 33 35 90 | 70 46 85
|

When I run it the UNIX way, number of seconds since 1/1/1970 12:00 AM, I get the following integer:
36435722120789

That converts to about 421709746.77 days which then means the date is... 1,154,578.36
years after 1970. If I treat the number as milliseconds since 1970, the date is 8/8/3124.

This sample date should be somewhere between 2000 and 2010.

I've run out of ideas. Any suggestions?