On Tue, 10 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> Sorry to jump it but I fail to see why should we rush a new proprietary type
> into the core, while it has a
> proper 3rd party solution.
> There could be lots of other types introduced into
> core by this reasoning.
In general I agree that introducing many different types directly
to HVM is not good idea. Especially when they are strictly bound
with some allocated resources. For such types HB_IT_POINTER seems
to be the best choice.
But I do not think that we can generalize it also for DATETIME type.
Just simply in current days in many database projects simple DATE fields
are replaced by DATETIME ones. Such fields are necessary to resolve some
problem, f.e. when you have to chose some orders from bigger set depending
on their time. Simple DATE field is not enough and is much easier to
replace it with DATETIME then creating some local solutions which are
not such trivial to implement as many people things, f.e. this function:
func curdatetime()
return (date()-ctod(""))+seconds()/86400
which should return datetime as number where integer part is Julian
day and fractional part is the time is buggy because there is race
condition between calling date() and seconds(). At midnight it may
give wrong results so it should be change to sth like:
func curdatetime()
local day, sec
while .t.
day := date()
sec := seconds()
if day == date()
exit
endif
enddo
return (day-ctod(""))+sec/86400
In the internet days it's also important to resolve the problem with
time comparing for users working in different time zones. Here also DATE
field is not enough. It's necessary to use DATETIME fields and operate
on UTC time, f.e. using function like: hb_utcDateTime() which returns
current UTC time to be able to compare values.
Please also note that relation local_time -> utc_time is not a function
so such conversions cannot be used in programs which have to work 365days
per year, f.e. to control some production processes. These and many others
things causes that project mangers quite often define pure DATE fields
as depreciated forcing datetime usage.
Harbour is designed to work with data base systems and we need direct
support for datetime types which can be used to exchange data between
different RDDs and HVM and which can be used in calculations and filter
expressions in such simple way as date is. It have to work in a way which
allows to easy replace pure DATE type with DATETIME if necessary.
> Datetime's only "merit" seems that some proprietary
> xbase dialects have already implemented it, plus xhb.
> The xhb implementation (particularly the syntax) stinks
> however, so if we decide to introduce it, it should be
> done properly, and only if it really gives proper benefits
> for the whole user base compared to the cost.
In practice this type is systematically more popular eliminating
pure DATE usage so for many people it will be aceptable to even
fully drop DATE support but intorduce DATETIME.
For me here it's not a question if we should introduce it but rather how.
In xHarbour simple DATE type is extended and can hold also time so it
does not use separate type for it. It's quite interesting solution but
it causes some small incompatibilities in DATE type arithmetic which can
be illustrated by this example:
d := date()
? d
? d + 1
? d + 0.5
? d + 0.5 + 0.5
just compare Clipper and xHarbour results.
If we do not make separate type for DATETIME type then we will have
to deal with the same problem.
Anyhow someone may say that respecting fractional part in the above code
is Clipper bug fixing so it's correct that it works in such way.
Interesting is this example:
? d + 0.5 + 0.5
Please note that the result is different then for:
? d + ( 0.5 + 0.5 )
In Harbour such effect can be exploited by -ko optimization, f.e. try this:
#pragma -ko-
? d + 0.5 + 0.5
#pragma -ko+
? d + 0.5 + 0.5
It's the reason why this (and also some other optimizations) are enabled
optionally by compiler switch.
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
with fractional part or we should use only one HB_IT_DATE type.
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.
We can accept and use above format though in such case I suggest to
introduce small modification and do not accept dot (.) as date delimiter
to avoid possible conflicts with PP and conversions to numbers though if
you think it's necessary we can implement it too.
As you can see this format allows to also define pure DATEs, f.e.:
d := { ^ 1998/12/31 }
It's probably more readable form of:
d := 0d19981231
which can be used in Harbour now.
xHarbour also accepts less then four digits in year, f.e.:
d := { ^ 98/12/31 }
but it gives 0098/12/31 as result and it does not generate error when
values out of range are used, f.e.:
d := { ^ 2008/13/34 }
but creates empty date. IMHO this should not be replicated because it's
usually programmer typo and should be reported as error or at least warning
during compilation.
In xHarbour it's also possible to use only time part, f.e.:
? { ^ 17:55:20 }
but here xHarbour sets in hidden way the day to 1899/12/30 so the
above code shows:
1899/12/30 17:55:20.00
I guess it's for some strict VFP and/or MS products compatibility.
I do not like it. It introduce sth what breaks DATETIME arithmetic.
I'd rather expect that { ^ 12:00:00 } will give the same internal
value as ( { ^ 2009/02/12 12:00:00 } - { ^ 2009/02/12 } ) as number
or datetime value and that ( { ^ 2008/12/31 } + { ^ 17:25:33 } )
will give the same result as { ^ 2008/12/31 17:25:33 } so IMO this
part should not be replicated.
> Instead of hard-wiring more core types for specific usages,
> it'd seem much more useful to consider this item from
> the TODO, which would smooth out the few remaining
> drawbacks of current possibilities:
> ---
> Detail...: Extended HB_IT_POINTER. In practice we can give them the
> same functionality as for objects and use them for fast
> creation objects at C level. We can also add HB_VALTYPE()
> function which will return the extended type name, f.e.
> "WINDOW", "FONT", "SOCKET" or anything what 3-rd party
> programmers may want to use. It will greatly simplify
> writing some libraries.
> ---
I agree with it (I wrote above text and still want to implement it)
but it does not mean that I want to replace all HVM types with it.
IMHO direct support for DATETIME in HVM is a must in current days.
We should only agree how it should be implemented.
If we agree how the final version should look then I can implement
it quite fast.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
