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 :-)
Hartmut Benz
Kris Jurka wrote:
>
>
> On Thu, 29 Mar 2007, Hartmut Benz wrote:
>
>> please find attached a small extension to PGInterval:
>> - getTimeInMillis - returns the number of milliseconds in the interval
>
> getLengthInMillis doesn't account for months.
>
> ONE_YEAR is seconds in a year instead of milliseconds.
>
> Shouldn't we use the server's definition instead of google's for a
> year's length in seconds:
> select extract(epoch from '1 year'::interval);
> date_part
> -----------
> 31557600
> (1 row)
>
>
>> - copying constructor PGInterval(PGInterval) for type-safe, cast-free
>> cloning
>> - now implements Comaparable<PGInterval>
>
> We can't use generics in this class because it must be buildable with
> older JDK versions.
>
> Also context diffs (-c) are preferred.
>
> Kris Jurka
>
