| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | peter(at)mccarthy(dot)co(dot)nz, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16561: timestamp with time zone microseconds inconsistently recorded correctly and incorrectly |
| Date: | 2020-07-30 01:39:57 |
| Message-ID: | CA+hUKGJAu7m=j3eDqoA-qwi+CbwT8YHtLbP5xQU7gHbpB-GCwQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Jul 30, 2020 at 11:52 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> One field being updated is a timestamp provided as UTC text representation
> (e.g. '2020-07-29T22:30:00.124248Z') but stored as timestamp with time
> zone. The timestamp sub-second component is not consistently written -
> sometimes it is stored correctly, sometime it is stored incorrectly. Always
> the sub second part of the time (including more significant digits) and
> never the date/time from seconds upwards.
Kia ora,
Just to rule out another theory, if you run pg_controldata -D pgdata,
you can see which storage format is used for timestamps:
Date/time type storage: 64-bit integers
Before release 10, it was possible for it to use floating point
storage instead of integers; I wonder if that could be a factor here.
There's a note about that here:
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Thomas | 2020-07-30 02:05:07 | Re: BUG #16561: timestamp with time zone microseconds inconsistently recorded correctly and incorrectly |
| Previous Message | Peter Thomas | 2020-07-30 01:00:35 | Re: BUG #16561: timestamp with time zone microseconds inconsistently recorded correctly and incorrectly |