Josh Kupershmidt writes:
> On Fri, Sep 3, 2010 at 4:01 PM, Tom Lane wrote:
>> Interesting. I can't imagine how you could have produced these with
>> plain COPY, since that would go through timestamptzin. Was it by any
>> chance a binary COPY? If so I could believe that funny timestamps could
>
On Fri, Sep 3, 2010 at 4:01 PM, Tom Lane wrote:
> Interesting. I can't imagine how you could have produced these with
> plain COPY, since that would go through timestamptzin. Was it by any
> chance a binary COPY? If so I could believe that funny timestamps could
> get in. Maybe some confusion
Josh Kupershmidt writes:
> On Fri, Sep 3, 2010 at 3:40 PM, Tom Lane wrote:
>> but I wonder what it was you actually did.
> I wonder myself :-) I encountered these timestamps while going through
> some C code I inherited which uses libpq to load several tables (such
> as myschema.strange_table in
On Fri, Sep 3, 2010 at 3:40 PM, Tom Lane wrote:
> Wow. You must have gotten those with the help of some arithmetic,
> because timestamptzin would never have produced them. I found out I can
> do
>
> regression=# select extract(epoch from ('2000-01-01 00:00:00'::timestamptz +
> '0.00
Josh Kupershmidt writes:
> EXTRACT(epoch ...) was what I was looking for:
> SELECT EXTRACT(epoch FROM ts - '1999-12-31 19:00:00-05'::timestamptz)
> FROM timestamps_test LIMIT 5;
>date_part
> ---
> 1.4120666068199e-309
> 1.4154982781624e-309
> 1.41550281692099e-309
[ trivia warning ]
I wrote:
> We don't make any great effort to expose that though. It looks like
> the closest value that timestamptzin makes different from zero is
> regression=# select extract(epoch from '1999-12-31 19:00:00.001-05' -
> '1999-12-31 19:00:00-05'::timestamptz) ;
>
On Fri, Sep 3, 2010 at 3:24 PM, Tom Lane wrote:
> regression=# select extract(epoch from ts - '1999-12-31
> 19:00:00-05'::timestamptz) from t1;
> date_part
> --
> 1.0761449337e-07
> 0
> (2 rows)
>
> This timestamp (2000-01-01 00:00 GMT) is actually
Josh Kupershmidt writes:
> On Fri, Sep 3, 2010 at 2:58 PM, Tom Lane wrote:
>> I'm thinking some of them might be different by submicrosecond amounts.
> Ah yes, this is likely why. pg_config says CONFIGURE = ...
> '--disable-integer-datetimes' ...
> But I'm having trouble seeing for sure whether
On Fri, Sep 3, 2010 at 2:58 PM, Tom Lane wrote:
> Is this installation using float or integer timestamps? If the former,
> it might be interesting to look at the subtraction result
> ts - '1999-12-31 19:00:00-05'::timestamptz
> I'm thinking some of them might be different by submicrosecond
Josh Kupershmidt writes:
> I've come across a puzzling situation with a table having a timestamp
> with time zone column. This column is full of values displaying
> exactly as '1999-12-31 19:00:00-05', but for some reason Postgres is
> treating some of these identical-seeming timestamps as being
>
Hi all,
I've come across a puzzling situation with a table having a timestamp
with time zone column. This column is full of values displaying
exactly as '1999-12-31 19:00:00-05', but for some reason Postgres is
treating some of these identical-seeming timestamps as being
different.
If I update al
11 matches
Mail list logo