On Wed, 11 Apr 2007, Hartmut Benz wrote:
> 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
You've left out the option of using existing functionality that handles
months and years (more) correctly.
Date d = new Date(System.currentTimeMillis());
PGInterval i = getIntervalFromSomewhere();
i.add(d);
long millis = d.getTime();
> 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.
>
Do you have intervals that have month/year components? If you don't then
it doesn't matter, but if we're advertising it as a general purpose
function then I think we need to handle it as accurately as possible.
> 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.
Yes, but it doesn't define month/year where the problems are so it doesn't
seem relevent.
Kris Jurka
