I have an old clipper .dbf file that store dates in a 3 bytes format
into a 10 characters string fields

//////////////////////////////////////////////
Date of Birth: 09/10/1899  Date of Death: 03/19/1987  Age:  87
	2BAEAA	=3D 2862762		2B8C3D =3D	2853949
	    AEAA   =3D 44714		    8C3D =3D 35901    =3D 1000110 0001 11101

Date of Burial: 03/27/1987 Funeral Home Name:
	2B8C76 =3D 2854006
	    8C76 =3D 35958
//////////////////////////////////////////////

I need the source code for the PackDate( "19870319" ) // inputs as
string
and the Unpackdate( "2B8C3D") //seems to be 3 bytes input as
string ??? ( "+=EE=3D" )

This is a very old program from the year 1992

Please, any help will be welcome

Thanks in advance for your cooperation

Regards

Jean Raymond
http://www.rayonline.com

Dear Jean3...:

On Feb 28, 12:50=A0pm, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
> I have an old clipper .dbf file that store dates
> in a 3 bytes format into a 10 characters string
> fields
>
> //////////////////////////////////////////////
> Date of Birth: 09/10/1899 =A0Date of Death: 03/19/1987 =A0Age: =A087
> =A0 =A0 =A0 =A0 2BAEAA =A0=3D 2862762 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2B8C3D =
=3D =A0 =A0 =A0 =A02853949
> =A0 =A0 =A0 =A0 =A0 =A0 AEAA =A0 =3D 44714 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A08C3D =3D 35901 =A0 =A0=3D 1000110 0001 11101
>
> Date of Burial: 03/27/1987 Funeral Home Name:
> =A0 =A0 =A0 =A0 2B8C76 =3D 2854006
> =A0 =A0 =A0 =A0 =A0 =A0 8C76 =3D 35958
> //////////////////////////////////////////////
>
> I need the source code for the
> PackDate( "19870319" ) // inputs as string
> and the Unpackdate( "2B8C3D") //seems to be 3 bytes
> input as string ??? ( "+=EE=3D" )
>
> This is a very old program from the year 1992
>
> Please, any help will be welcome

Wrong language, but might be the same algorithm...
http://www.petesqbsite.com/sections/tutorials/zines/qbcm/10-winer.html
.... down to the section "Minimizing Disk Usage".  May or may not be
the same function.

And here...
http://www.phatcode.net/res/227/files/btu_book.pdf
.... down to page 186 of the (slow loading) PDF

You'll just have to dope out what the "base" is for the three bytes,
perhaps the year will be "add 1970 to the char value of the first
byte, less 32", the month might be "the char value of the second byte,
less 32", and the day might be "the char value of the third byte, less
32".

Hopefully you can compare your attempts to the program output for a
couple of values?

David A. Smith

Dear Jean3...:

On Feb 28, 12:50=A0pm, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
....
> PackDate( "19870319" )
> Unpackdate( "2B8C3D")

These are NOT keywords in the Clipper language in version 5.01.  May
either be "home rolled", or a third party library.

Good luck.

David A. Smith

Jean

There is a library called SIX3 that included a couple of functions to 
convert dates to/from packed format (3 bytes long).
That functions are DTOP() and PTOD().

That library is still supported by the company at 
http://vistasoftware.com/sixrdd.asp
But I don't know if they are the ones used in your application.

If you wish to test a different aproach, you can download xharbour compiler 
for free at http://free.xharbour.com/free.xHarbour.com/Index.html, and use 
the corresponding functions (I use the commercial version, that includes 
something equivalent: sx_dtop and sx_ptod).

Have luck!

Best regards/Saludos
---
Claudio Voskian
Cell: (+54 911) 4435-4789
aol/msn/skype/y!: cvoskian - icq: 18122595


"Jean3Riv@gmail.com" <jean3riv@gmail.com> escribi� en el mensaje 
news:1deaf270-1bc4-4c10-beb3-0429d9b83e61@j27g2000yqn.googlegroups.com...
I have an old clipper .dbf file that store dates in a 3 bytes format
into a 10 characters string fields

//////////////////////////////////////////////
Date of Birth: 09/10/1899  Date of Death: 03/19/1987  Age:  87
2BAEAA = 2862762 2B8C3D = 2853949
    AEAA   = 44714     8C3D = 35901    = 1000110 0001 11101

Date of Burial: 03/27/1987 Funeral Home Name:
2B8C76 = 2854006
    8C76 = 35958
//////////////////////////////////////////////

I need the source code for the PackDate( "19870319" ) // inputs as
string
and the Unpackdate( "2B8C3D") //seems to be 3 bytes input as
string ??? ( "+�=" )

This is a very old program from the year 1992

Please, any help will be welcome

Thanks in advance for your cooperation

Regards

Jean Raymond
http://www.rayonline.com

Hey Claudio,

> If you wish to test a different aproach, you can download xharbour compiler
> for free at http://free.xharbour.com/free.xHarbour.com/Index.html,

You added a , (comma) to the url which makes it not working anymore ;-)

The right URL is
http://free.xHarbour.com

Patrick

In article  <1deaf270-1bc4-4c10-beb3-0429d9b83e61@j27g2000yqn.googlegroups.com>
           jean3riv@gmail.com "Jean3Riv@gmail.com" writes:

> I have an old clipper .dbf file that store dates in a 3 bytes format
> into a 10 characters string fields
> 
> //////////////////////////////////////////////
> Date of Birth: 09/10/1899  Date of Death: 03/19/1987  Age:  87
>         2BAEAA  = 2862762             2B8C3D =      2853949
>             AEAA   = 44714                8C3D = 35901    = 1000110 0001
>  11101
> 
> Date of Burial: 03/27/1987 Funeral Home Name:
>         2B8C76 = 2854006
>             8C76 = 35958
> //////////////////////////////////////////////
> 
> I need the source code for the PackDate( "19870319" ) // inputs as
> string
> and the Unpackdate( "2B8C3D") //seems to be 3 bytes input as
> string ??? ( "+�=" )
> 
> This is a very old program from the year 1992
> 
> Please, any help will be welcome
> 
> Thanks in advance for your cooperation
> 
> Regards
> 
> Jean Raymond

Please post some more examples -- it would help us to discover the 
algorithm used. Something like:

packdate("1980101") gives ???
packdate("1980102") gives ???

packdate("1980601") gives ???
packdate("1980602") gives ???

packdate("20000101") gives ???
packdate("20000102") gives ???

packdate("20000601") gives ???
packdate("20000602") gives ???

Looking at the example you already supplied it would seem that the hex 
value (assuming it is a hex value) decreases as the date increases 
which is rather strange...

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."

On Feb 28, 9:34=A0pm, "CV-XH" <mixxell-nosp...@hotmail.com> wrote:
> Jean
>
> There is a library called SIX3 that included a couple of functions to
> convert dates to/from packed format (3 bytes long).
> That functions are DTOP() and PTOD().
>
> That library is still supported by the company athttp://vistasoftware.com=
/sixrdd.asp
> But I don't know if they are the ones used in your application.
>
> If you wish to test a different aproach, you can download xharbour compil=
er
> for free athttp://free.xharbour.com/free.xHarbour.com/Index.html, and use
> the corresponding functions (I use the commercial version, that includes
> something equivalent: sx_dtop and sx_ptod).
>
> Have luck!
>
> Best regards/Saludos
> ---
> Claudio Voskian
> Cell: (+54 911) 4435-4789
> aol/msn/skype/y!: cvoskian - icq: 18122595
>
> "Jean3...@gmail.com" <jean3...@gmail.com> escribi en el mensajenews:1deaf=
270-1bc4-4c10-beb3-0429d9b83e61@j27g2000yqn.googlegroups.com...
> I have an old clipper .dbf file that store dates in a 3 bytes format
> into a 10 characters string fields
>
> //////////////////////////////////////////////
> Date of Birth: 09/10/1899 =A0Date of Death: 03/19/1987 =A0Age: =A087
> 2BAEAA =3D 2862762 2B8C3D =3D 2853949
> =A0 =A0 AEAA =A0 =3D 44714 =A0 =A0 8C3D =3D 35901 =A0 =A0=3D 1000110 0001=
 11101
>
> Date of Burial: 03/27/1987 Funeral Home Name:
> 2B8C76 =3D 2854006
> =A0 =A0 8C76 =3D 35958
> //////////////////////////////////////////////
>
> I need the source code for the PackDate( "19870319" ) // inputs as
> string
> and the Unpackdate( "2B8C3D") //seems to be 3 bytes input as
> string ??? ( "+ =3D" )
>
> This is a very old program from the year 1992
>
> Please, any help will be welcome
>
> Thanks in advance for your cooperation
>
> Regards
>
> Jean Raymondhttp://www.rayonline.com

Those are hex to decimal to binary conversions, but I don't know how
they relate to the dates.

I am sad to report that the built in functions cited do not return hex
values vaguely close to what was reported:
? strtohex( sx_dtop( stod( "18990910" )))
\\ 0ED72A

? strtohex( sx_dtop( stod( "19870319" )))
\\ 0F8673

? strtohex( sx_dtop( stod( "19870327" )))
\\ 0F867B

David A. Smith

Hi Pete,
> Please post some more examples -- it would help us to discover the 
> algorithm used. Something like:

I agree, need some patterns to sovle this one, something in line of:

FOR y := 1980 TO 1990
  FOR m := 1 TO 12
   FOR d := 1 to 5
     ?PackDate(StrTran(Str(y, 4, 0) + Str(m, 2, 0) + ;
               Str(d, 2, 0), " ", "0"))
   NEXT
  NEXT
NEXT
> Looking at the example you already supplied it would seem that the hex 
> value (assuming it is a hex value) decreases as the date increases 
> which is rather strange...
Yes picked that up too.  Maybe the number is days before MAX_DATE?

FUNCTION PackDate(cStr)
   nDays := SToD("21001231") - dDate
   cHex := Some hex on nDays
RETURN cHex

Regards,

Johan Nel
Pretoria, South Africa.

On 1 mar, 12:42, p...@nospam.demon.co.uk wrote:
> In article =A0<1deaf270-1bc4-4c10-beb3-0429d9b83...@j27g2000yqn.googlegro=
ups.com>
> =A0 =A0 =A0 =A0 =A0 =A0jean3...@gmail.com "Jean3...@gmail.com" writes:
>
>
>
> > I have an old clipper .dbf file that store dates in a 3 bytes format
> > into a 10 characters string fields
>
> > //////////////////////////////////////////////
> > Date of Birth: 09/10/1899 =A0Date of Death: 03/19/1987 =A0Age: =A087
> > =A0 =A0 =A0 =A0 2BAEAA =A0=3D 2862762 =A0 =A0 =A0 =A0 =A0 =A0 2B8C3D =
=3D =A0 =A0 =A02853949
> > =A0 =A0 =A0 =A0 =A0 =A0 AEAA =A0 =3D 44714 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A08C3D =3D 35901 =A0 =A0=3D 1000110 0001
> > =A011101
>
> > Date of Burial: 03/27/1987 Funeral Home Name:
> > =A0 =A0 =A0 =A0 2B8C76 =3D 2854006
> > =A0 =A0 =A0 =A0 =A0 =A0 8C76 =3D 35958
> > //////////////////////////////////////////////
>
> > I need the source code for the PackDate( "19870319" ) // inputs as
> > string
> > and the Unpackdate( "2B8C3D") //seems to be 3 bytes input as
> > string ??? ( "+=EE=3D" )
>
> > This is a very old program from the year 1992
>
> > Please, any help will be welcome
>
> > Thanks in advance for your cooperation
>
> > Regards
>
> > Jean Raymond
>
> Please post some more examples -- it would help us to discover the
> algorithm used. Something like:
>
> packdate("1980101") gives ???
> packdate("1980102") gives ???
>
> packdate("1980601") gives ???
> packdate("1980602") gives ???
>
> packdate("20000101") gives ???
> packdate("20000102") gives ???
>
> packdate("20000601") gives ???
> packdate("20000602") gives ???
>
> Looking at the example you already supplied it would seem that the hex
> value (assuming it is a hex value) decreases as the date increases
> which is rather strange...
>
> Pete
> --
> =A0 =A0"We have not inherited the earth from our ancestors,
> =A0 =A0 we have borrowed it from our descendants."
//////////////////////////////////
Pete ( repost for all to see )

Name: ******              ,  ******
Date of Birth: 09/10/1899  Date of Death: 03/19/1987  Age:  87
	2BAEAA	=3D 2862762		2B8C3D =3D	2853949

Date of Burial: 03/27/1987 Funeral Home Name:
	2B8C76 =3D 2854006

Space No.:    5  Space Suffix:    Map Location: B5
Name: ******             ,  ******            ******
Date of Birth: 00/00/0000  Date of Death: 06/15/1953  Age:  82
	808080			2B852D =3D2852141
Date of Burial: 06/19/1953 Funeral Home Name:
	2B852B	=3D 2852139

Space No.:    6  Space Suffix:    Map Location: B6
Name: ******             ,  *******
Date of Birth: 00/00/0000  Date of Death: 00/00/0000  Age:  78
	808080			808080
Date of Burial: 01/31/1947 Funeral Home Name:
	2B382B

Space No.:    7  Space Suffix:    Map Location: B7
Name: ******            ,  ******         *******
Date of Birth: 00/00/0000  Date of Death: 00/00/1907  Age:   0
	808080			2BDD80 =3D 2874752
Date of Burial: 00/00/0000 Funeral Home Name:
	808080

Space No.:    1  Space Suffix:    Map Location: B2
Name: *******             ,  *******          *
Date of Birth: 02/08/1906  Date of Death: 12/17/1965  Age:  59
	2B2B2B	=3D 2829099		2B2B91 =3D 2829201
Date of Burial: 12/20/1965 Funeral Home Name:
	2B2B94	=3D 2829204

Space No.:    2  Space Suffix:    Map Location: B3
Name: ********             , ********   //record 5
Date of Birth: 05/11/1915  Date of Death: 00/00/0000  Age:  23
	2B66AB	=3D 2844331		808080 =3D8421504
Date of Burial: 09/29/1938 Funeral Home Name:
	2B2D2B  	2829611
////////////////////////////////////

The database has 37335 records, therefore very hard to do the
conversion
by hand using the original EXE.

----------------------------------------
PS: Funny thing here
Date of Death: 00/00/1907  Age:   0
	2BDD80 =3D 2874752
----------------------------------------
Thanks for helping me

Jean

On Mar 2, 6:35 am, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
....
> 09/10/1899	2BAEAA
> 02/08/1906	2B2B2B
> 05/11/1915	2B66AB
> 09/29/1938	2B2D2B
> 01/31/1947	2B382B
> 06/15/1953	2B852D
> 06/19/1953	2B852B
> 12/17/1965	2B2B91
> 12/20/1965	2B2B94
> 03/19/1987	2B8C3D
> 03/27/1987	2B8C76

I have compared the dates to the hex values provided, and I have
assumed all possible swappings of the bytes (6) (even swapped the
nibble orders, 6 more), and I cannot get a monotonic ascending or
descending order.  So it is likely not an "endian" problem, nor is it
likely a power-and-sign-truncated single precision number.

Be interesting to see what gives.

Jean, if you can sort by date, try to give us a few records with the
same month and day, but different years... then the same month and
year, but different days... then the same day and year, but different
months.  They have been asking you for clues to how the data is
packed, and not so much interested in the "outliers" (such as invalid
dates).

Finally, we may have to have the full structure dump of this file.

And it may be that it is encoded / encrypted, and the problem is
insoluble without the code (or a professional cracker).

David A. Smith

On 2 mar, 10:48, dlzc <dl...@cox.net> wrote:
> On Mar 2, 6:35 am, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
> ...
>
> > 09/10/1899 2BAEAA
> > 02/08/1906 2B2B2B
> > 05/11/1915 2B66AB
> > 09/29/1938 2B2D2B
> > 01/31/1947 2B382B
> > 06/15/1953 2B852D
> > 06/19/1953 2B852B
> > 12/17/1965 2B2B91
> > 12/20/1965 2B2B94
> > 03/19/1987 2B8C3D
> > 03/27/1987 2B8C76
>
> I have compared the dates to the hex values provided, and I have
> assumed all possible swappings of the bytes (6) (even swapped the
> nibble orders, 6 more), and I cannot get a monotonic ascending or
> descending order. =A0So it is likely not an "endian" problem, nor is it
> likely a power-and-sign-truncated single precision number.
>
> Be interesting to see what gives.
>
> Jean, if you can sort by date, try to give us a few records with the
> same month and day, but different years... then the same month and
> year, but different days... then the same day and year, but different
> months. =A0They have been asking you for clues to how the data is
> packed, and not so much interested in the "outliers" (such as invalid
> dates).
>
> Finally, we may have to have the full structure dump of this file.
>
> And it may be that it is encoded / encrypted, and the problem is
> insoluble without the code (or a professional cracker).
>
> David A. Smith

David
Here some other values
Same month
01/02/1875 =3D DDADA2 =3D  14527906
01/03/1876 =3D DD2DA3 =3D  14495139
01/04/1877 =3D DD2BA4 =3D  14494628

Same day
01/15/1910 =3D DD2B2B =3D  14494507
02/15/1911 =3D DD2B28 =3D  14494504
03/15/1912 =3D DD2B95 =3D  14494613

Same year
10/19/1845 =3D 2B2B22 =3D  2829090
11/20/1845 =3D 2B5F2D =3D  2842413
12/21/1845 =3D 2B616E =3D  2842990

Very bizarre stuff

Regards

Jean

In article  <9e22dcbf-c1f9-411b-8058-b534f10e2543@d2g2000yqa.googlegroups.com>
           jean3riv@gmail.com "Jean3Riv@gmail.com" writes:

> On 1 mar, 12:42, p...@nospam.demon.co.uk wrote:
[snip]
> > Please post some more examples -- it would help us to discover the
> > algorithm used. Something like:
> >
> > packdate("1980101") gives ???
> > packdate("1980102") gives ???
> >
> > packdate("1980601") gives ???
> > packdate("1980602") gives ???
> >
> > packdate("20000101") gives ???
> > packdate("20000102") gives ???
> >
> > packdate("20000601") gives ???
> > packdate("20000602") gives ???
> >
> > Looking at the example you already supplied it would seem that the hex
> > value (assuming it is a hex value) decreases as the date increases
> > which is rather strange...
[..]
> //////////////////////////////////
> Pete ( repost for all to see )
> 
> Name: ******              ,  ******
> Date of Birth: 09/10/1899  Date of Death: 03/19/1987  Age:  87
>         2BAEAA  = 2862762             2B8C3D =      2853949
> 
> Date of Burial: 03/27/1987 Funeral Home Name:
>         2B8C76 = 2854006
> 
> Space No.:    5  Space Suffix:    Map Location: B5
> Name: ******             ,  ******            ******
> Date of Birth: 00/00/0000  Date of Death: 06/15/1953  Age:  82
>         808080                  2B852D =2852141
> Date of Burial: 06/19/1953 Funeral Home Name:
>         2B852B  = 2852139
> 
> Space No.:    6  Space Suffix:    Map Location: B6
> Name: ******             ,  *******
> Date of Birth: 00/00/0000  Date of Death: 00/00/0000  Age:  78
>         808080                  808080
> Date of Burial: 01/31/1947 Funeral Home Name:
>         2B382B
> 
> Space No.:    7  Space Suffix:    Map Location: B7
> Name: ******            ,  ******         *******
> Date of Birth: 00/00/0000  Date of Death: 00/00/1907  Age:   0
>         808080                  2BDD80 = 2874752
> Date of Burial: 00/00/0000 Funeral Home Name:
>         808080

These are interesting -- enlightening even.  It looks possible or 
perhaps probable that the packed date is XOR'd with 0x808080, maybe in 
an attempt to avoid the packed date containing a NUL (0x00) byte?  I 
will check what the packed dates look like when XOR'd back -- this 
might explain why some of the dates you posted originally appear to be 
smaller values for later dates -- and see if there is a consistent 
pattern that emerges...

> Space No.:    1  Space Suffix:    Map Location: B2
> Name: *******             ,  *******          *
> Date of Birth: 02/08/1906  Date of Death: 12/17/1965  Age:  59
>         2B2B2B  = 2829099             2B2B91 = 2829201
> Date of Burial: 12/20/1965 Funeral Home Name:
>         2B2B94  = 2829204
> 
> Space No.:    2  Space Suffix:    Map Location: B3
> Name: ********             , ********   //record 5
> Date of Birth: 05/11/1915  Date of Death: 00/00/0000  Age:  23
>         2B66AB  = 2844331             808080 =8421504
> Date of Burial: 09/29/1938 Funeral Home Name:
>         2B2D2B          2829611
> ////////////////////////////////////
> 
> The database has 37335 records, therefore very hard to do the
> conversion by hand using the original EXE.

You have a .EXE?  If you can make that available for download it could 
be disassembled and save a lot of time second-guessing the algorithms 
for packdate() and unpackdate()!  Even better would be a .LIB or .OBJ 
that contains these functions -- do you have either?  If not, the .EXE 
will do.

> ----------------------------------------
> PS: Funny thing here
> Date of Death: 00/00/1907  Age:   0
>         2BDD80 = 2874752
> ----------------------------------------

That looks like either a shortcoming in the algorithm ;-) or some 
corruption in the database.

> Thanks for helping me
> 
> Jean

We folk in c.l.c relish a good challenge :-)

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."

Dear Jean3...:

On Mar 2, 11:19=A0am, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
....
> Very bizarre stuff

Can you import with this program, from some other format?  If so, you
might be able to create records in the other format, with every
possible date in each date field, and let it make the hard part of a
lookup table for you.

Sometimes, depending on the programmer, you might even have an
identical structure, except the compressed date fields are actual date
fields, and see if it will "convert" the "older" format to the
"compressed" upon opening...

David A. Smith

hi,

>I need the source code for the PackDate( "19870319" )
>and the Unpackdate( "2B8C3D")

i found this :

***************************************************************************************************
* ------------------------------------------------------------------------
* Program......: EXPDEMO.PRG, Demo of EXPAND.LIB v3.02
* Author.......: Pepijn Smits.
* Version......: 3.02
* Date.........: Jan 1990 v1, May v1.5, Aug v2.0, Oct v2.5
*   Mar 91, v3.0, Sep v3.02
* Copyright....: (c)1990, Pepijn Smits Softwarebureau.
* Notes........: Clipper 'Demo' program of some of the functions in the
*                Expand Library. This program demonstrates most of EXPAND's
*                functions
* ------------------------------------------------------------------------
* Be sure to Link in EXPAND.LIB next to CLIPPER and EXTEND!
*

....
@17,31 say "Real-Time date.....: "+Dtoc( UnpackDate(PackDate(RealDate())))
@18,31 say "Real-Time time.....: "+UnpackTime(PackTime(RealTime()))

***************************************************************************************************
but it is a S87 LIB and Function seem to be ASM ...

i "think" v5.x LIB was later ... but i�m not shure if these Function are 
still need for v5.x ?

did S87 have Field Type "D" ?


you can try to find v5.x LIB @ http://www.the-oasis.net/

greetings by OHR
Jimmy 

Dear AUGE_OHR:

On Mar 2, 2:02=A0pm, "AUGE_OHR" <AUGE_OHR*NOS...@WEB.DE> wrote:
....
> did S87 have Field Type "D" ?

Yes.  Also Memo.

Good score on the EXPAND.LIB
The Oasis had contact information for the Expand library:

Asiapac Network
PO Box 231
Maylands WA 6051
Australia
expand(at)asiapac(dot)dialix(dot)oz(dot)au

Unlikely it is still "hot"...
http://www.hotfrog.com.au/Companies/Asiapac-Network

David A. Smith

Dear p...:

On Mar 2, 12:16=A0pm, p...@nospam.demon.co.uk wrote:
....
> We folk in c.l.c relish a good challenge :-)

And given hot dogs and bun, we can challenge a good relish too!

David A. Smith

Dear p...:

On Mar 2, 12:16=A0pm, p...@nospam.demon.co.uk wrote:
....
> These are interesting -- enlightening even. =A0It
> looks possible or perhaps probable that the
> packed date is XOR'd with 0x808080, maybe in
> an attempt to avoid the packed date containing
> a NUL (0x00) byte?

I checked, sorted on date order, month order, and day order, and
xoring 808080 does not produce and ascending list in either bytes 1,
2, or 3.

date prov. - value provided xored with 0x808080
DATE
10/19/1845 - ABABA2
11/20/1845 - ABDFAD
12/21/1845 - ABE1EE
01/02/1875 - 5D2D22
01/03/1876 - 5DAD23
01/04/1877 - 5DAB24
09/10/1899 - AB2E2A
02/08/1906 - ABABAB
01/15/1910 - 5DABAB
02/15/1911 - 5DABA8
03/15/1912 - 5DAB15
05/11/1915 - ABE62B
09/29/1938 - ABADAB
01/31/1947 - ABB8AB
06/15/1953 - AB05AD
06/19/1953 - AB05AB
12/17/1965 - ABAB11
12/20/1965 - ABAB14
03/19/1987 - AB0CBD
03/27/1987 - AB0CF6

MONTH
01/02/1875 - 5D2D22
01/03/1876 - 5DAD23
01/04/1877 - 5DAB24
01/15/1910 - 5DABAB
01/31/1947 - ABB8AB
02/08/1906 - ABABAB
02/15/1911 - 5DABA8
03/15/1912 - 5DAB15
03/19/1987 - AB0CBD
03/27/1987 - AB0CF6
05/11/1915 - ABE62B
06/15/1953 - AB05AD
06/19/1953 - AB05AB
09/10/1899 - AB2E2A
09/29/1938 - ABADAB
10/19/1845 - ABABA2
11/20/1845 - ABDFAD
12/17/1965 - ABAB11
12/20/1965 - ABAB14
12/21/1845 - ABE1EE

DAY
01/02/1875 - 5D2D22
01/03/1876 - 5DAD23
01/04/1877 - 5DAB24
02/08/1906 - ABABAB
09/10/1899 - AB2E2A
05/11/1915 - ABE62B
01/15/1910 - 5DABAB
02/15/1911 - 5DABA8
03/15/1912 - 5DAB15
06/15/1953 - AB05AD
12/17/1965 - ABAB11
03/19/1987 - AB0CBD
06/19/1953 - AB05AB
10/19/1845 - ABABA2
11/20/1845 - ABDFAD
12/20/1965 - ABAB14
12/21/1845 - ABE1EE
03/27/1987 - AB0CF6
09/29/1938 - ABADAB
01/31/1947 - ABB8AB

Month ironed it out the best on byte 1...

David A. Smith

David,

What about:

Function PackDate(cDate)
   Local dDate, dOffSet := CtoD("2099/12/31") // Max date of Clipper?
   Local nOffSet
   dDate := StoD(cDate)
   nOffSet := dOffSet - dDate
Return Hex(nOffSet)

I just got a gutfeel that a "future" date possibly MAX_DATE is used as 
offset point, due to the fact that the number is decreasing with 
increasing dates.


Just my 2c worth.

Johan Nel
Pretoria, South Africa.

dlzc wrote:
> Dear p...:
> 
> On Mar 2, 12:16 pm, p...@nospam.demon.co.uk wrote:
> ...
>> These are interesting -- enlightening even.  It
>> looks possible or perhaps probable that the
>> packed date is XOR'd with 0x808080, maybe in
>> an attempt to avoid the packed date containing
>> a NUL (0x00) byte?

In article  <d1c686fa-2fea-4c9b-b013-4f010d54729d@t31g2000prh.googlegroups.com>
           dlzc1@cox.net "dlzc" writes:

> Dear p...:
> 
> On Mar 2, 12:16�pm, p...@nospam.demon.co.uk wrote:
> ...
> > These are interesting -- enlightening even. �It
> > looks possible or perhaps probable that the
> > packed date is XOR'd with 0x808080, maybe in
> > an attempt to avoid the packed date containing
> > a NUL (0x00) byte?
> 
> I checked, sorted on date order, month order, and day order, and
> xoring 808080 does not produce and ascending list in either bytes 1,
> 2, or 3.
> 
> date prov. - value provided xored with 0x808080
> DATE
> 10/19/1845 - ABABA2
> 11/20/1845 - ABDFAD
> 12/21/1845 - ABE1EE
> 01/02/1875 - 5D2D22
> 01/03/1876 - 5DAD23
> 01/04/1877 - 5DAB24
> 09/10/1899 - AB2E2A
> 02/08/1906 - ABABAB
> 01/15/1910 - 5DABAB
> 02/15/1911 - 5DABA8
> 03/15/1912 - 5DAB15
> 05/11/1915 - ABE62B
> 09/29/1938 - ABADAB
> 01/31/1947 - ABB8AB
> 06/15/1953 - AB05AD
> 06/19/1953 - AB05AB
> 12/17/1965 - ABAB11
> 12/20/1965 - ABAB14
> 03/19/1987 - AB0CBD
> 03/27/1987 - AB0CF6
> 
> MONTH
> 01/02/1875 - 5D2D22
> 01/03/1876 - 5DAD23
> 01/04/1877 - 5DAB24
> 01/15/1910 - 5DABAB
> 01/31/1947 - ABB8AB
> 02/08/1906 - ABABAB
> 02/15/1911 - 5DABA8
> 03/15/1912 - 5DAB15
> 03/19/1987 - AB0CBD
> 03/27/1987 - AB0CF6
> 05/11/1915 - ABE62B
> 06/15/1953 - AB05AD
> 06/19/1953 - AB05AB
> 09/10/1899 - AB2E2A
> 09/29/1938 - ABADAB
> 10/19/1845 - ABABA2
> 11/20/1845 - ABDFAD
> 12/17/1965 - ABAB11
> 12/20/1965 - ABAB14
> 12/21/1845 - ABE1EE
> 
> DAY
> 01/02/1875 - 5D2D22
> 01/03/1876 - 5DAD23
> 01/04/1877 - 5DAB24
> 02/08/1906 - ABABAB
> 09/10/1899 - AB2E2A
> 05/11/1915 - ABE62B
> 01/15/1910 - 5DABAB
> 02/15/1911 - 5DABA8
> 03/15/1912 - 5DAB15
> 06/15/1953 - AB05AD
> 12/17/1965 - ABAB11
> 03/19/1987 - AB0CBD
> 06/19/1953 - AB05AB
> 10/19/1845 - ABABA2
> 11/20/1845 - ABDFAD
> 12/20/1965 - ABAB14
> 12/21/1845 - ABE1EE
> 03/27/1987 - AB0CF6
> 09/29/1938 - ABADAB
> 01/31/1947 - ABB8AB
> 
> Month ironed it out the best on byte 1...
> 
> David A. Smith

Yeah -- I came to the same conclusion :-(  Some of the example dates 
close to each other suggest that the day is encoded in the byte (or 
the low order bits of that byte) whilst others do not...

As a wild guess I'd say it looks like some sort of LZ compression is 
being used with perhaps XOR 0x80 used to guard against "dangerous" 
bytes.  If so, rather overkill IMHO unless the aim was to encrypt as 
well as pack the dates.

However, Jimmy looks like he might have found the original library so 
with luck Jean will have the result he was looking for and we nosy 
types can discover the original code.

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."

Dear Johan Nel:

On Mar 2, 10:18=A0pm, Johan Nel <johan....@xsinet.co.za> wrote:
> What about:
>
> Function PackDate(cDate)
> =A0 =A0Local dDate, dOffSet :=3D CtoD("2099/12/31")
>      // Max date of Clipper?
> =A0 =A0Local nOffSet
> =A0 =A0dDate :=3D StoD(cDate)
> =A0 =A0nOffSet :=3D dOffSet - dDate
> Return Hex(nOffSet)
>
> I just got a gutfeel that a "future" date
> possibly MAX_DATE is used as offset point, due
> to the fact that the number is decreasing with
> increasing dates.
>
> Just my 2c worth.

It neither decreases nor increases montonically.  So it is not NOTted,
and it is not a reference to MAXDATE, and it is not a "number of days
since past or future date".

So in other words, it is entirely useless for date sorting in any
quick way.

David A. Smith

<pete@nospam.demon.co.uk> wrote in message 
news:1267597413snz@nospam.demon.co.uk...
> In article 
> <d1c686fa-2fea-4c9b-b013-4f010d54729d@t31g2000prh.googlegroups.com>
>           dlzc1@cox.net "dlzc" writes:
>
> As a wild guess I'd say it looks like some sort of LZ compression is
> being used with perhaps XOR 0x80 used to guard against "dangerous"
> bytes.  If so, rather overkill IMHO unless the aim was to encrypt as
> well as pack the dates.
>
> Pete

but having presented a few longer sequences of dates [some of them crossing 
month and/or year boundaries], with their encoded counterparts could give 
some additional ideas. or at least having shown one consecutive 50-days 
sequence 

On 2 mar, 16:02, "AUGE_OHR" <AUGE_OHR*NOS...@WEB.DE> wrote:
> hi,
>
> >I need the source code for the PackDate( "19870319" )
> >and the Unpackdate( "2B8C3D")
>
> i found this :
>
> *************************************************************************=
**************************
> * -----------------------------------------------------------------------=
-
> * Program......: EXPDEMO.PRG, Demo of EXPAND.LIB v3.02
> * Author.......: Pepijn Smits.
> * Version......: 3.02
> * Date.........: Jan 1990 v1, May v1.5, Aug v2.0, Oct v2.5
> * =A0 Mar 91, v3.0, Sep v3.02
> * Copyright....: (c)1990, Pepijn Smits Softwarebureau.
> * Notes........: Clipper 'Demo' program of some of the functions in the
> * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Expand Library. This program demonstrate=
s most of EXPAND's
> * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0functions
> * -----------------------------------------------------------------------=
-
> * Be sure to Link in EXPAND.LIB next to CLIPPER and EXTEND!
> *
>
> ...
> @17,31 say "Real-Time date.....: "+Dtoc( UnpackDate(PackDate(RealDate()))=
)
> @18,31 say "Real-Time time.....: "+UnpackTime(PackTime(RealTime()))
>
> *************************************************************************=
**************************
> but it is a S87 LIB and Function seem to be ASM ...
>
> i "think" v5.x LIB was later ... but i=B4m not shure if these Function ar=
e
> still need for v5.x ?
>
> did S87 have Field Type "D" ?
>
> you can try to find v5.x LIB @http://www.the-oasis.net/
>
> greetings by OHR
> Jimmy

Jimmy

I have made some tests, and the functions from Expand.lib
give 2 bytes, <Quote from expand.ng, nothern guide
///////////////////////////
  Function:    PackDate()

               This function packs a Clipper Date variable into a
               2 byte string. This packaging method is very handy
               as it can be used in various ways, where using 2
               chars instead of 8 might come in handy. Examples
               of such usage are in the storing of Data
               variables, but also in the indexing on existing
               databases, as the Packed date is stored in such a
               way that order is preserved. The PackDate (and
               relating) function(s) have been written in
               assembly completely, so that it also offers a
               tremendous run-time saving as the code is very
               efficient (handy in indices for instance). One can
               always use the UnPackDate() function to recover
               the packed date.
               NOTE: PackDate only works on dates AFTER 1980,
               dates before 1980 give unpredictable results. This
               was needed because PackDate conforms to the DOS
               date and time packing format.
///////////////////////////////////////
My stuff gives 3 bytes format, therefore it is those functions +
I have dates before 1980

Thanks for your input

Jean Raymond
http://www.rayonliine.com

Dear Jean3...:

On Mar 4, 8:48=A0am, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
....
> My stuff gives 3 bytes format, therefore it
> is those functions + I have dates before 1980

The pattern is too difficult to discern.  You'll need a professional,
or you'll need to consider using the program to create a conversion
table for you.

Does it have the capability to import information?

David A. Smith

Jean,

Here are some ideas regarding a conclusion:

0000/00/00 -> 0x80,0x80,0x80
0x80 is 128.  This indicates to me that the LowerBytes of the characters 
are used.

I would like to see what the PackDate() result is for 00000001

I have a gut feel that he program actually use the least significant bits 
of the string provided and return something from a new concatenated bits 
string that is converted to hex again.  Also we looking at Significant 
chars that might have an offset -32 or -48

See if you can play with:
808080 -> 00000000
2B2B2B -> 19060208
?      -> 99999999

If we look at the patterns below all starting with 2B, I assume this has 
something to do with the Year +-1800 ~ +-2000 all will be in the range 2B??

Xor(0x808080, 0x2B2B2B) = 0xB2B2B2

Hope this gives some ideas.

Regards,

Johan Nel
Pretoria, South Africa.

Jean3Riv@gmail.com wrote:
> On 2 mar, 10:48, dlzc <dl...@cox.net> wrote:
>> On Mar 2, 6:35 am, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
>> ...
>>
>>> 09/10/1899 2BAEAA
>>> 02/08/1906 2B2B2B
>>> 05/11/1915 2B66AB
>>> 09/29/1938 2B2D2B
>>> 01/31/1947 2B382B
>>> 06/15/1953 2B852D
>>> 06/19/1953 2B852B
>>> 12/17/1965 2B2B91
>>> 12/20/1965 2B2B94
>>> 03/19/1987 2B8C3D
>>> 03/27/1987 2B8C76
>> I have compared the dates to the hex values provided, and I have
>> assumed all possible swappings of the bytes (6) (even swapped the
>> nibble orders, 6 more), and I cannot get a monotonic ascending or
>> descending order.  So it is likely not an "endian" problem, nor is it
>> likely a power-and-sign-truncated single precision number.
>>
>> Be interesting to see what gives.
>>
>> Jean, if you can sort by date, try to give us a few records with the
>> same month and day, but different years... then the same month and
>> year, but different days... then the same day and year, but different
>> months.  They have been asking you for clues to how the data is
>> packed, and not so much interested in the "outliers" (such as invalid
>> dates).
>>
>> Finally, we may have to have the full structure dump of this file.
>>
>> And it may be that it is encoded / encrypted, and the problem is
>> insoluble without the code (or a professional cracker).
>>
>> David A. Smith
> 
> David
> Here some other values
> Same month
> 01/02/1875 = DDADA2 =  14527906
> 01/03/1876 = DD2DA3 =  14495139
> 01/04/1877 = DD2BA4 =  14494628
> 
> Same day
> 01/15/1910 = DD2B2B =  14494507
> 02/15/1911 = DD2B28 =  14494504
> 03/15/1912 = DD2B95 =  14494613
> 
> Same year
> 10/19/1845 = 2B2B22 =  2829090
> 11/20/1845 = 2B5F2D =  2842413
> 12/21/1845 = 2B616E =  2842990
> 
> Very bizarre stuff
> 
> Regards
> 
> Jean

Jean,

If you know assembler this might be the algorithm that you looking for. 
Obviously you will have to play with offsets 0x808080 etc to get it to 
work for your scenario:

http://www.hpmuseum.org/software/71/71pack3.htm

HTH,

Johan Nel
Pretoria, South Africa.

Jean3Riv@gmail.com wrote:
> I have an old clipper .dbf file that store dates in a 3 bytes format
> into a 10 characters string fields
> 
> //////////////////////////////////////////////
> Date of Birth: 09/10/1899  Date of Death: 03/19/1987  Age:  87
> 	2BAEAA	= 2862762		2B8C3D =	2853949
> 	    AEAA   = 44714		    8C3D = 35901    = 1000110 0001 11101
> 
> Date of Burial: 03/27/1987 Funeral Home Name:
> 	2B8C76 = 2854006
> 	    8C76 = 35958
> //////////////////////////////////////////////
> 
> I need the source code for the PackDate( "19870319" ) // inputs as
> string
> and the Unpackdate( "2B8C3D") //seems to be 3 bytes input as
> string ??? ( "+�=" )
> 
> This is a very old program from the year 1992
> 
> Please, any help will be welcome
> 
> Thanks in advance for your cooperation
> 
> Regards
> 
> Jean Raymond
> http://www.rayonline.com
> 

In article  <hmtfi0$g4b$1@news.eternal-september.org>
           johan.nel@xsinet.co.za "Johan Nel" writes:

> Jean,
> 
> If you know assembler this might be the algorithm that you looking for. 
> Obviously you will have to play with offsets 0x808080 etc to get it to 
> work for your scenario:
> 
> http://www.hpmuseum.org/software/71/71pack3.htm
> 
> HTH,
> 
> Johan Nel
> Pretoria, South Africa.

Hi Johan,

That looks like a useful link -- I've too have been on the 'net 
looking but turned up nothing -- will take a look later (out of 
curiosity...)

Like you I've been experimenting with bit-encoding: day of month can 
be encoded in 5 bits, month in 4 bits, leaving 15 bits for year (for a 
range of >30000 years if unsigned).  However, so far none of the 
results look anything like they "should", regardless of how the bit 
fields are ordered.

The encoding is certainly _not_ straightforward, even allowing for 
bytes being biased with 0x80:

19651217  2B2B91
19651220  2B2B94
These two suggest that the day is encoded in the RH bits, whilst

18451019  2B2B22
19060208  2B2B2B
suggests that dates over 60 years apart are different _only_ in the 
final 4 bits!

Hopefully the hpmuseum algorithm will shed some light!

Pete

> Jean3Riv@gmail.com wrote:
> > I have an old clipper .dbf file that store dates in a 3 bytes format
> > into a 10 characters string fields
> > 
> > //////////////////////////////////////////////
> > Date of Birth: 09/10/1899  Date of Death: 03/19/1987  Age:  87
> >       2BAEAA  = 2862762               2B8C3D =        2853949
> >           AEAA   = 44714                  8C3D = 35901    = 1000110 0001
>  11101
> > 
> > Date of Burial: 03/27/1987 Funeral Home Name:
> >       2B8C76 = 2854006
> >           8C76 = 35958
> > //////////////////////////////////////////////
> > 
> > I need the source code for the PackDate( "19870319" ) // inputs as
> > string
> > and the Unpackdate( "2B8C3D") //seems to be 3 bytes input as
> > string ??? ( "+�=" )
> > 
> > This is a very old program from the year 1992
> > 
> > Please, any help will be welcome
> > 
> > Thanks in advance for your cooperation
> > 
> > Regards
> > 
> > Jean Raymond
> > http://www.rayonline.com
> > 
> 
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."

> Hi Johan,
> 
> That looks like a useful link -- I've too have been on the 'net 
> looking but turned up nothing -- will take a look later (out of 
> curiosity...)
> 
> Like you I've been experimenting with bit-encoding: day of month can 
> be encoded in 5 bits, month in 4 bits, leaving 15 bits for year (for a 
> range of >30000 years if unsigned).  However, so far none of the 
> results look anything like they "should", regardless of how the bit 
> fields are ordered.
> 
> The encoding is certainly _not_ straightforward, even allowing for 
> bytes being biased with 0x80:
> 
> 19651217  2B2B91
> 19651220  2B2B94
> These two suggest that the day is encoded in the RH bits, whilst
> 
> 18451019  2B2B22
> 19060208  2B2B2B
> suggests that dates over 60 years apart are different _only_ in the 
> final 4 bits!
> 
> Hopefully the hpmuseum algorithm will shed some light!
> 
> Pete
Hi Pete,

I did play with the idea of (sorry if it is Visual Object, been long since 
I actually had a Clipper manual with me so not always sure which functions 
where VO and which were Clipper<g>):

cBits := I2Bin(Asc(SubStr(cDate, i, 1)) - 48

That shifts "0" to be represented by 0x00, since we only need to represent 
0-9 in some way or the other.

 From some other reading it was also suggested to shift by 32 (space 
becomes 0x00).

This allows for using the least significant 4 bits and concat them back 
into 8 bits, I however always gets 4 hex characters back, not 3... :(

Also, something that might come into play each of the 3 characters might 
be a combination of (CC * Factor + MM) + (YY * Factor + DD).  My gut feels 
says it might be that because why is 1854 - 1965 all starting with 2B? 
For all practical purposes we can assume Century and Decade to be in the 
range "00" - "99", month "00" - "12" and day "00" - "31".  So 99 + 31 = 
130 and 99 + 12 = 111, it might be that due to the 0x80=128 might shift 
the remainder of something into the other 112-128 combination that will 
not be used in the month part of the formula.

Regards,

Johan

On Feb 28, 1:50=A0pm, "Jean3...@gmail.com" <jean3...@gmail.com> wrote:
> I have an old clipper .dbf file that store dates in a 3 bytes format
> into a 10 characters string fields
>
> //////////////////////////////////////////////
> Date of Birth: 09/10/1899 =A0Date of Death: 03/19/1987 =A0Age: =A087
> =A0 =A0 =A0 =A0 2BAEAA =A0=3D 2862762 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2B8C3D =
=3D =A0 =A0 =A0 =A02853949
> =A0 =A0 =A0 =A0 =A0 =A0 AEAA =A0 =3D 44714 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A08C3D =3D 35901 =A0 =A0=3D 1000110 0001 11101
>
> Date of Burial: 03/27/1987 Funeral Home Name:
> =A0 =A0 =A0 =A0 2B8C76 =3D 2854006
> =A0 =A0 =A0 =A0 =A0 =A0 8C76 =3D 35958
> //////////////////////////////////////////////
>
> I need the source code for the PackDate( "19870319" ) // inputs as
> string
> and theUnpackdate( "2B8C3D") //seems to be 3 bytes input as
> string ??? ( "+=EE=3D" )
>
> This is a very old program from the year 1992
>
> Please, any help will be welcome
>
> Thanks in advance for your cooperation
>
> Regards
>
> Jean Raymondhttp://www.rayonline.com

PROCEDURE UnPackDate
LPARAMETERS lcDate

LOCAL lnDate, lnDay, lnMonth, lnYear


*-- Empty date
IF lcDate =3D CHR(128) + CHR(128) + CHR(128)
  RETURN "0000/00/00"
ENDIF


*-- Convert 3 chars to 24 bit number
lnDate =3D ASC(SUBSTR(lcDate, 3, 1)) + 256 * ASC(SUBSTR(lcDate, 2, 1))
+
65536 * ASC(SUBSTR(lcDate, 1, 1))


IF SUBSTR(lcDate, 3, 1) =3D CHR(128)
  *-- Day not defined
  lnDay =3D 0
ELSE
  *-- Unpack day number
  lnDay =3D lnDate % 32
ENDIF


lnDate =3D BITRSHIFT(lnDate, 5)


*-- Unpack month
lnMonth =3D lnDate % 4
lnDate =3D BITRSHIFT(lnDate, 3)
lnMonth =3D lnMonth + 4 * (lnDate % 4)


lnDate =3D BITRSHIFT(lnDate, 2)


*-- Adjust date when month is not defined
IF NOT BITTEST(lnDate, 6)
  lnDate =3D BITCLEAR(lnDate, 5)
ENDIF


*-- Unpack year
lnYear =3D lnDate % 64
lnDate =3D BITRSHIFT(lnDate, 7)
lnYear =3D lnYear + 64 * (lnDate % 32)


*-- Return string YYYY/MM/DD
RETURN TRANSFORM(lnYear, "@L 9999") + '/' + TRANSFORM(lnMonth, "@L
99") + '/' + TRANSFORM(lnDay, "@L 99")