Re: Binary encoding of TIMESTAMP WITH TIME ZONE

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!"

In response to

Browse pgsql-general by date

  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