On Fri, 29 Apr 2005, Oliver Siegmar wrote:
> On Friday 29 April 2005 10:01, Kris Jurka wrote:
> > On Sat, 23 Apr 2005, Oliver Siegmar wrote:
> > > The applied patch contains all modifications from the last one
> > > (pgjdbc_interval2.diff) as well as a replacement for the regular
> > > expression code.
> >
> > Here's my version of it. Changes:
> > - Always use noniso format for sending intervals to the backend.
> > This makes it possible to support a seconds field of 90. Also
> > don't need to worry about signs of fields.
>
> Sounds reasonable. But I'm not sure if we should support "oversized" values -
> I see no requirement for it, and it adds a lot of possible trouble.
Well the constructor and setXXX methods allow it. I'm not saying we need
to go out of our way to make all excessive values possible, but if we can
allow say 90 seconds with no other harm, why not? If we're going to
prevent it, we should prevent it at set time, not at getValue time.
> > My one remaining question is about the roll function. What is the purpose
> > of roll, don't we want add?
>
> a) because the database doesn't return "oversized" values - so it doesn't
> matter using add() or roll()
Surely it does, consider a calendar 2001-01-01 00:00:45 and an interval of
20 seconds. roll gives 2001-01-01 00:00:05 while add gives the
correct 2001-01-01 00:01:05
> > Also in the roll method the milliseconds calculation should round the
> > value so 0.6006 seconds becomes 601 milliseconds.
>
> Why? When is the current implementation doing wrong?
>
final int milliseconds = microseconds / 1000 - seconds * 1000;
Shouldn't this be "microseconds + 500 / 1000" (although it does need to
account for the sign.
Kris Jurka
