From: | Mark Morgan Lloyd <markMLl(dot)pgsql-general(at)telemetry(dot)co(dot)uk> |
---|---|
To: | pgsql-general(at)PostgreSQL(dot)org |
Subject: | Re: timestamps, formatting, and internals |
Date: | 2012-06-03 07:43:59 |
Message-ID: | jqf4k0$5tc$1@pye-srv-01.telemetry.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jasen Betts wrote:
> On 2012-05-29, David Salisbury <salisbury(at)globe(dot)gov> wrote:
>>
>> On 5/27/12 12:25 AM, Jasen Betts wrote:
>>> The query: "show integer_datetimes;" should return 'on' which means
>>> timestamps are microsecond precision if it returns 'off' your database
>>> was built with floating point timstamps and equality tests will be
>>> unreliable,
>> I find that rather interesting. I was told that I was losing microseconds
>> when I extracted an epoch from the difference between two timestamps and casted
>> that value to an integer. So if I have integer timestamps ( your case above )
>> I get microseconds, but integer epochs is without microseconds?
>
> yeah, the microseconds appear as fractions of seconds, so in the
> conversion to integer epoch they get rounded off.
I think you need to consider what you're actually computing and
measuring. My understanding is that Meeus's Equation of Time calculation
is good to something like 250mSec so that's the limit of your accuracy,
but as soon as you start taking refraction and atmospheric turbulence
into account- even with the Sun high above the horizon- you're going to
degrade that.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
From | Date | Subject | |
---|---|---|---|
Next Message | Misa Simic | 2012-06-03 10:00:57 | Re: SELECT issue with references to different tables |
Previous Message | Tom Lane | 2012-06-02 21:10:03 | Re: Re: [GENERAL] pg_upgrade from 9.0.7 to 9.1.3: duplicate key pg_authid_oid_index |