On Thu, 12 Feb 2009, Angel Pais wrote:
> Also:
> A date is represented in DBF as "YYYYMMDD"
No. It's only one of few representations in DBF format:
1. { "D", 8, 0 } // stirng as above
2. { "D", 4, 0 } // julian date as 32bit binary little endian integer number
3. { "D", 3, 0 } // julian date as 24bit binary little endian integer number
4. { "V", 3, 0 } // packed YYYYMMDD date in SIX3/ADS compatible format
> Wil timestamp be represented in DBFS with 17 characters ?
> eg: YYYYMMDDHHMMSSmmm bieng the last 3 millisecs.
No. I know about two formats in which timestamp can be stored in DBFs
1. { "T", 8, 0 } // timestamp as julian date and number of milliseconds
// in two 32bit binary little endian integer numbers
2. { "T", 4, 0 } // time in milliseconds as 24bit binary little endian
// integer number
There is also:
{ "@", 8, 0 } // it's the same as { "T", 8, 0 }, Harbour supports it.
Harbur also supports:
{ "=", 8, 0 } // the same representation as { "T", 8, 0 } but it's
// automatically updated when record is added/modified
> Another one:
> Why timestand has to have a literal representation since dates don't have it
> ?
Harbour support constant date value:
? 0d20090212
Non constant values cannot be used to initialize static variables, f.e.
try in Clipper:
static s1 := ctod( "01/01/01" )
static s2 := stod( "20010101" )
static s3 := stod( "20090101" ) - stod( "20010101" )
Harbour optimize STOD() and HB_STOD() during compilation so s2 and s3
above can be compiled but ctod() cannot be optimized at compile time
because it depends on _SET_DATEFORMAT run time setting.
Constant values are not strictly necessary but makes life easier.
Direct support for constant values can be replaced by functions optimized
at compile time. It's a little bit more expensive (slower) but for compiler
it does not cause big problems. Probably only in macrocompiler the speed
is important.
> In dates we use dtos(), stod(), dtoc() ctod()
> So in timestanp we should use ttos(), stot(), ttoc(), ttoc() don´t we ?
We can but we used to not intorduce new public functions without HB_ prefix
to not cause problems with 3-rd party or user code which may already use
functions with the same names.
Anyhow here we have yet another aspect. These functions are already
implemented in some xbase compatible languages. For sure in CLIP and
AFAIK in VFP.
In such case we may want to keep the exact names for compatibility with
these languages, f.e. to be able to open index which has key expression
like "CLIENT_ID + TTOS( SALES_TIME )".
But it means that our implementation of above functions has to be _EXACTLY_
compatible with them (of course if possible).
In CLIP TTOC()/CTOT() functions respect RT settings for date and time
formatting. TTOS()/STOT() functions use fixed format "YYYY-MM-DD HH:MM:SS".
I do not know how these functions works in VFP. Can someone help here?
In xHarbour TTOS()/STOT() functions use fixed format "YYYYMMDDHHMMSS.FFF"
so we cannot be CLIP and xHarbour compatible in the same time.
Does anyone knows sth about these functions in other languages?
If the results are not compatible then probably the best choice is
not implementing TTOS()/STOT() at all so users can write their own
wrappers depending on preferred compatibility, f.e. for CLIP compatibility:
FUNC TTOS( tTimeStamp )
RETURN HB_TTOC( tTimeStamp, "YYYY-MM-DD HH:MM:SS" )
or:
FUNC TTOS( tTimeStamp )
RETURN HB_TTOC( tTimeStamp, "YYYYMMDDHHMMSS.FFF" )
for xHarbour.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
