Re: [Libreoffice] [REVIEW][3-4] date change regression fdo#44385

On 01/17/2012 04:46 AM, Noel Power wrote:
> On 16/01/12 16:59, Eike Rathke wrote:
> > > 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() ) ) )
> > That one (b) looks good.
> ok, good you don't see additional problems then
> > > >  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() ) )
> > I don't spot sense in 2*today() =>  2124-02-02;-)
> >
> >    Eike
> well like I said neither do I but iirc Andrew mentioned he could think 
> of some possible strange use cases ( maybe I misunderstood him ) 
> Anyway I will commit the solution we agreed on. Andrew, if still feel 
> strongly enough that the 'Date' type should be preserved then I guess 
> you can submit an extra patch and rational to the list.
>
> thanks again
>
> Noel

Sorry for the delay in my response.... Ripped some muscles in my leg and 
I am a bit behind in my email.... It was exacerbated by the fact that 
any email that includes the mailing list in any way is all filtered into 
the list (so I needed to read a few hundred messages to find these).

So, when might someone multiply dates? Well, people that choose to store 
a date or time delta in the native type will do it for sure. Find the 
difference between two dates, perform some manipulation on that, etc.

My primary concerns

1. Change in behavior that may break existing code.

2. Previous behavior was never flagged as an issue, and may arguably be 
considered logical to some. for example, storing a "delta" in the native 
type.

3. The rules are more complicated now and require complex examples to 
explain; for example, time_1 + time_2 + time_3 returns a date but time_1 
+ time_2 does not. We cannot simply state that math done with dates or 
including a date returns a date.

I expect, however, that this will allow the majority case to function.

If we desire to argue that it makes no sense to multiply two dates 
together, then why not simply call it an error? (I am not advocating this)

This will now fail for all code that chooses to store a time / date 
difference in the time / date type. Sadly, this is an error that will 
only be discovered when that particular code is run. I found the code 
while trying to fix existing code that was sent to me... They wanted to 
know why it failed in LibO.

--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php