Re: Small addition to PGInterval - Mailing list pgsql-jdbc

In my application I have a value stored as interval in the DB that I use
in my application for various checks against the system time
(System.currentTimeMillis()) and other times. My alternatives were:
- store the interval as ms in the DB making it less readable
- implement a conversion routine myself converting from PGInterval
values to ms in my code
- perform this conversion in PGInterval itself

I found the third to be the most attractive. It puts the code to the
data it belongs to. The basis "ms" is the basic 'coinage' most program
work with. It exposes (implicitly), what postgres thinks how long a year is.

Independent of which number of ms per year/month is the correct one, I
think it is more important to have identical values in the postgres
server and the client. Therefore, your suggestion to use the server
value instead of some other value was the right one.

By the way, I do not see such a problem with your code example. Wherever
I see programs working with timers I see similar constructions. See, for
instance, javax.management.timer.Timer: it defines millisecond-based
constants for second, minute, hour, day, and week to be used very
similar to your code fragment.

The biggest problem I see is that the class now takes a position
regarding how many ms are in an 'average' month and year. But postgres
does that already in the server.


Hartmut Benz


Kris Jurka wrote:
>
>
> On Wed, 11 Apr 2007, Hartmut Benz wrote:
>
>> Thanks for pointing this out. I corrected the bug (months) and use
>> the server definition for both year and month. It is a bit
>> problematic to determine the 'correct' number of seconds in these
>> kind of intervals because there are so many of them :-)
>
> Does getLengthInMillis have any external value or is it solely useful
> for implementing compareTo?  I fear that people will try to do
> something like:
>
> Date d = new Date();
> PGInterval i = new PGInterval("1 year");
> d.setTime(d.getTime() + i.getLengthInMillis());
>
> instead of using the exising i.add(d) method.  As you mention it's not
> entirely clear what value it should be returning, so I'd prefer not to
> expose it unless you have a more useful use case.
>
> Kris Jurka
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>