From: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Binary encoding of TIMESTAMP WITH TIME ZONE |
Date: | 2020-06-05 15:30:57 |
Message-ID: | 20200605153057.GA11484@hjp.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2020-06-04 20:32:51 -0400, Tom Lane wrote:
> Joe Abbate <jma(at)freedomcircle(dot)com> writes:
> > However, when using the same query using the Rust adapter the transition
> > to a new row started showing up after midgnight GMT. I opened an issue
> > on Github (https://github.com/sfackler/rust-postgres/issues/608 ) and
> > the maintainer claimed the Rust adapter *had* to initialize timezone to
> > UTC in order to properly convert "to and from time datatypes". I
> > pointed out that the timezone offset is available in psql and psycopg2,
> > but then he replied the binary encoding of timestamptz does *not*
> > include the timezone offset.
>
> Indeed it does not, just as the on-disk format for it does not. The
> representation is effectively always in UTC. If you have some other
> timezone setting selected, timestamptz_out rotates to that zone for
> display purposes ... but the binary format doesn't.
However, the explanation still sounds off. I'm not familiar with Rust,
but I wouild expect the Rust time type to be based on Unix time_t or
some variant of it (maybe milliseconds as in Java, or nanoseconds or a
different epoch). That also doesn't include a timezone, so conversion
should be straightforward and not require any timezone to be involved.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
From | Date | Subject | |
---|---|---|---|
Next Message | Koen De Groote | 2020-06-05 15:34:34 | Re: Index no longer being used, destroying and recreating it restores use. |
Previous Message | Achilleas Mantzios | 2020-06-05 15:02:45 | Re: Oracle vs. PostgreSQL - a comment |