Обсуждение: Possible bug in PGInterval class

Поиск
Список
Период
Сортировка

Possible bug in PGInterval class

От
Ľubomír Varga
Дата:
Hi.

I have noticed imho bad behaviour of add methods for PGInterval class.
(org.postgresql.util.PGInterval)

First is unlogical adding sum to parameter and not to object on which is
method invoked. (this is also writen in javadoc, so I accept it)

Second, critical for me, is to not using modulo in addition. So if you add 55
minutes to 55 minutes, you get 110 minutes instead of 1 hour and 50 minutes.

Is this bug or feature? Should I use to postprocessing of sql query result
some other date classes? (joda time, or java date class...)

Thanks for answer.

PS: If it is not bug, please add some description to javadoc also to this
behaviour.

I am using 8.4-701 build and source...

--
Odborník na všetko je zlý odborník. Ja sa snažím byť výnimkou potvrdzujúcou
pravidlo.

Re: Possible bug in PGInterval class

От
Kris Jurka
Дата:

On Mon, 31 Aug 2009, ?ubom?r Varga wrote:

> I have noticed imho bad behaviour of add methods for PGInterval class.
> (org.postgresql.util.PGInterval)
>
> First is unlogical adding sum to parameter and not to object on which is
> method invoked. (this is also writen in javadoc, so I accept it)

This is to be similar to the add(Date) and add(Calendar) functions.  For
them you wan't to add the interval to the passed object.

> Second, critical for me, is to not using modulo in addition. So if you
> add 55 minutes to 55 minutes, you get 110 minutes instead of 1 hour and
> 50 minutes.

For minutes and hours, it would be OK, but when rolling hours into days or
days into months, context is needed to know if you are near a daylight
saving time change or how many days are in the month.  For this reason we
don't manipulate the values and leave them as is.

Kris Jurka

Re: Possible bug in PGInterval class

От
Oliver Jowett
Дата:
Kris Jurka wrote:
>
>
> On Mon, 31 Aug 2009, ?ubom?r Varga wrote:

>> First is unlogical adding sum to parameter and not to object on which is
>> method invoked. (this is also writen in javadoc, so I accept it)
>
> This is to be similar to the add(Date) and add(Calendar) functions.  For
> them you wan't to add the interval to the passed object.

Maybe rename them to addTo() ?

-O

Re: Possible bug in PGInterval class

От
Ľubomír Varga
Дата:
On Wednesday 02 September 2009 02:01:11 Kris Jurka wrote:
>...
> > Second, critical for me, is to not using modulo in addition. So if you
> > add 55 minutes to 55 minutes, you get 110 minutes instead of 1 hour and
> > 50 minutes.
>
> For minutes and hours, it would be OK, but when rolling hours into days or
> days into months, context is needed to know if you are near a daylight
> saving time change or how many days are in the month.  For this reason we
> don't manipulate the values and leave them as is.
>

What about to add some function which will "normalize" interval and make
minutes lees than 60, hours lees than 24 and seconds lees than 60? I do it
like this:

        PGInterval duration = ...;
        int add = 0;
        if(duration.getSeconds() > 60) {
            add = (int)Math.floor(duration.getSeconds() / 60);
            duration.setSeconds(duration.getSeconds() - (add * 60));
            duration.setMinutes(duration.getMinutes() + add);
        }
        if(duration.getMinutes() > 60) {
            add = duration.getMinutes() / 60;
            duration.setMinutes(duration.getMinutes() - (add * 60));
            duration.setHours(duration.getHours() + add);
        }

        if(duration.getHours() > 24) {
            add = duration.getHours() / 24;
            duration.setHours(duration.getHours() - (add * 24));
            duration.setDays(duration.getDays() + add);
        }

Just an suggestion for future generations of developers which will use
PGInterval for postprocessing selected data like me...

PS: Thanks for explanation, I fully accept that reason.

--
Odborník na všetko je zlý odborník. Ja sa snažím byť výnimkou potvrdzujúcou
pravidlo.