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 10:52:42 |
Message-ID: | 461CBDFA.6080205@ti-wmc.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
>
Attachment | Content-Type | Size |
---|---|---|
PGInterval.diff.gz | application/gzip | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2007-04-11 11:10:24 | Re: Small addition to PGInterval |
Previous Message | Xavier Poinsard | 2007-04-11 08:51:05 | Re: random escape function |