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

By 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:

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?


This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

A guess but I remember

by Tony Hopkinson In reply to Can anyone figure out the ...

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

Collapse -

CTIME from my Unix days...

by Charles Bundy In reply to Can anyone figure out the ...

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

Collapse -


by Charles Bundy In reply to CTIME from my Unix days.. ...

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

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

Collapse -

Not sure

by jbwilson1120 In reply to Yikes...

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:

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?

Related Discussions

Related Forums