Hi Przemek, 3) by no means. 2) could be good, but not with this problematic case, which is a very important and common expression.
I vote for 1/b) as the most natural one. Brgds, Viktor On Thu, Feb 12, 2009 at 3:44 PM, Przemyslaw Czerpak <dru...@acn.waw.pl>wrote: > Hi All, > > On Tue, 10 Feb 2009, Przemyslaw Czerpak wrote: > > We have to define also supported math operations and item type for > results. > > I suggest to make it date compatible too and define that date + timestamp > > and timestamp + date gives timestamp as result. The list of legal > operations > > will look like: > > <t> + <t> => <t> > > <t> - <t> => <n> > > <t> + <n> => <t> > > <n> + <t> => <t> > > <t> - <n> => <t> > > > > <d> + <t> => <t> > > <t> + <d> => <t> > > <d> - <t> => <n> > > <t> - <d> => <n> > > We also have to define relation operators behavior: ==, =, <, >, <=, >= > when DATE and TIMESTAMP are used. > We have the following choices: > 1. compare only date part ignoring the time with the exception for == > operator which will make exact comparison. For this exact comparision > we also have two choices: > a. strict type checking => results always .F. > b. if dates are equal and time part in TIMESTAMP item is 0 then > result is .T. otherwise .F. > 2. convert DATE to TIMESTAMP setting 00:00 as TIME and compare items > like two TIMESTAMP values. > In such way works xHarbour. > 3. use asymmetric comparison like for strings so: > FIELD->DATETIME <= date() > will work but > date() => FIELD->DATETIME > won't. > > Now my opinion: > I do not like 3-rd version because it may be too complicated for users > and normal usage. > 2-nd one has some bad side effect. User cannot use DATE in filter > expressions like: > FIELD->DATETIME <= date() > because date() value after conversion will have time part set to 0 > so it will be smaller then TIMESTAMP value calculated today (except > the midnight). > For me the best choice is 1. > Probably 1b but I also found 1a as usable in some cases. The question > is how deeply we want to hide difference between DATE and TIMESTAMP > types. If it should be fully hidden like for numbers (we do not make > any difference between HB_IT_INTEGER, HB_IT_LONG and HB_IT_DOUBLE in > == comparision) then we should chose 1b. > > I would like to hear your opinions. > > best regards, > Przemek > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour >
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
