Hi Eike,
On 16/01/12 13:01, Eike Rathke wrote:
Hi Noel, On Friday, 2012-01-13 09:51:33 +0000, Noel Power wrote:
this change ( the variant ) is what is on master, here the intention
is as Andrew pointed out ( in a previous mail discussing the
regression ) to allow operations on date types return dates (
regardless of the operation ) which seems reasonable.
Not every operation on date types should return a date,
I have to admit I was swayed by Andrew's point that letting the
operations just return Dates seems more consistent.Also it would seem to
me subtraction should at least mirror the behaviour of addition.
e.g.
something = date() + 1 ' something becomes a variant date ( 1 day
into the future )
something = date() - 1 ' something becomes a variant date ( 1 day
in the past ) ( Note: previously this would just be a strange double
value e.g the numeric rep of the date type )
Although I don't really see the point of exponential or division etc.
operations on dates, keeping the type didn't seem like it would cause
any problems ( and simplified the code )
However, given previous bad experiences with basic with seemingly minor
changes in combination with your query I am getting nervous :-/
i.e. substracting two dates should return a number of days (I don't
think adding/multiplying/dividing two dates makes sense, but it should
return a number of days as well).
hmm Date 'operation' Date puts a different spin on things :-/
with the change on master
dim tomorrow as Date
dim yesterday as Date
tomorrow = date() + 1
yesterday = date() - 1
result = tomorrow - yesterday ' previously would have given 2 as a
result with a type variant/double but now gives a strange date ( result
of trying to convert 2 into a date )
and of course... that's not good :-(
However I'd still like to see macro code like
something = date() - 1
return a date just like the addition case
We have a number of choices
a) safest, just restore the old code
b) not so risky ( I think ), and... would change the present behaviour
in consistent way for treatment of minus operator
- if( GetType() == SbxDATE || rOp.GetType() == SbxDATE )
+ if( ( eOp == SbxPLUS || eOp == SbxMINUS ) && ( (
GetType() == SbxDATE || rOp.GetType() == SbxDATE ) && ( GetType() !=
rOp.GetType() ) ) )
c) risker variant of b that allows all operations on a date type to
retain it's date type
- if( GetType() == SbxDATE || rOp.GetType() == SbxDATE )
+ if( ( GetType() == SbxDATE || rOp.GetType() ==
SbxDATE ) && ( GetType() != rOp.GetType() ) )
Given past history I'd choose b) but I'd like to hear other opinions (
also cc'ing Andrew ) and of course be glad of some other eyes for the change
regards,
Noel
Context
Re: [Libreoffice] [REVIEW][3-4] date change regression fdo#44385 · Andrew Douglas Pitonyak
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.