Hi Przemek and all,
Okay, I understand the reasons and benefits, so it all
comes down how we implement it in Harbour.
I vote for adding a new type to have a clear case
rather than mixing this feature into current "D" type.
Besides creating backward compatibility problems
it would also make porting code very difficult between
different xbase dialects, in essence this would be
showcase for the "hidden extension" effect we try
to avoid in Harbour.
New type ID could be "T" (as timestamp or time).
? d + 0.5 + 0.5
> just compare Clipper and xHarbour results.
xHarbour never built properly on my system, nor
could I use any binaries, so I'll skip that, but I believe you :)
> Anyhow the rest of datetime RT arithmetic in xHarbour looks fine for me
> though I haven't tested all conditions.
> The one question to the group is if we want to use separate type marked
> in type HB_ITEM member (f.e. HB_IT_DATETIME) to keep strict Clipper
> compatibility for DATE type when it's increased/decreased by number
My definite vote for this one.
> The second part is declaring DATETIME constants in source code.
> It's not strictly necessary (f.e. Clipper does not support DATE constants
> at all) but it's usable. xHarbour uses VFP syntax here:
> VFP strict datetime format looks like:
> {^YYYY/MM/DD[,][HH[:MM[:SS][.CCC]][A|P]]}
> VFP accepts slash, dot or hyphen as date delimiter and 12 or 24-hour
> formatted time.
> If only hours are included in time part then comma have to be used to
> separate date and time parts or it's necessary to follow the hours with
> a colon.
> In the semi PP notation this format can be defined as:
> { ^ <YEAR> <sep:/.-> <MONTH> <sep:/.-> <DAY> [[<sep2:,>]
> [ <HOUR> [ : <MIN> [ : <SEC> [ . <FRAQ> ] ] ] [A[M]|P[M]] ] }
> I do not know how many other languages also supports similar notation.
> If you have some propositions or examples from other languages then
> please send it here.
This syntax is an ugly nightmare rarely seen in proper
language design, and the product which introduced it
is now dead, so in case we want to support the above,
I'd suggest to implementing it in PP only (protected by
VFP guards), and avoid it Harbour code completely.
Instead, I'd suggest a set of function, just like Clipper
uses for dates:
- hb_time() -> <tCurrentDateTime>
- hb_stot( "language independent string representation of date/time" ) ->
<tValue>
- hb_ttos() -> <cValue> language independent string repr of date/time, easy
to parse with fixed positions ("YYYYMMDDHHMMSSFF")
- hb_ctot( "freeform date/time representation" ) -> <tValue>
- hb_ttoc( <tValue>[, <cFormat> ] ) -> <cValue> freeform date/time
representation (also controllable by Set( _SET_TIMEFORMAT ) )
These functions could be optimized at compile
time to native internal representation, just like
current date functions are doing.
For explicit constant notation, I'd suggest:
- 0tYYYYMMDDHHMMSSFF (allowing elements to be dropped from the right)
- 0tYYYYMMDD
(same as the format used by hb_ttos()/hb_stot())
Notice that above solution makes it easy to switch
from current DATE to DATETIME (TIMESTAMP or TIME
for simplicity), by merely replacing appropriate
functions and constant notation to the TIME equivalents.
Current functions dealing with DATE types can be
modified to also handle TIME types, without breaking
backward compatibility, so YEAR(), MONTH(), DOW(),
and all similar, even in 3rd party products can be
used just like before.
Of course, several additional new functions become
possible: HB_HOUR(), HB_MINUTE().
We should decide what time granularity to have and
what to return for: <tTime1> - <tTime2> -> ? (seconds,
millisecs, else? probably the least resolution we allow).
We could have additional functions dealing with time
differences:
HB_TIMEDIFFINMIN( <tTime1>, <tTime2> -> <nMinutes>
HB_TIMEDIFFINSEC( <tTime1>, <tTime2> -> <nSeconds>
HB_TIMEDIFFINDAY( <tTime1>, <tTime2> -> <nDays>
etc...
For pure TIME representations (where the date is irrelevant)
0t00000000125801 may be used, or some special functions
helping that, anyhow internally the date might be simply
empty in this case.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
