Skip site navigation (1) Skip section navigation (2)

Re: Small addition to PGInterval

From: Hartmut Benz <hartmut(dot)benz(at)ti-wmc(dot)nl>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Small addition to PGInterval
Date: 2007-04-11 15:11:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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, 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

In response to


pgsql-jdbc by date

Next:From: Kris JurkaDate: 2007-04-11 17:41:40
Subject: Re: random escape function
Previous:From: Tom LaneDate: 2007-04-11 14:48:43
Subject: Re: random escape function

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group