On 2021-09-21 13:43:46 -0400, Dave Cramer wrote:
>
>
> On Tue, 21 Sept 2021 at 13:40, Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
>
> On 2021-09-21 13:34:21 -0400, Dave Cramer wrote:
> > On Tue, 21 Sept 2021 at 13:20, Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
> > On 2021-09-21 20:50:44 +1200, Tim Uckun wrote:
> > Calling a type which doesn't include a timezone
> > "timestamp with timezone" is - how do I put this? - more than just
> > weird.
> >
> > I would say this is a perspective thing. It's a timestamp with a time
> > zone from the client's perspective.
>
> I disagree. When I read back the value the original timezone is lost. So
> it clearly DOESN'T store the timestamp WITH the timezone.
>
>
> I never said it stored the timezone. I said that it has a timezone.
The raison d’être of a database is to store data. If some data isn't
stored, the database doesn't have it, in my opinion.
As a different example, I can store a number with 15 decimal digits in a float4
and I can get 15 decimal digits out again:
hjp=> create table t (f float4);
CREATE TABLE
hjp=> insert into t(f) values(1.23456789012345);
INSERT 0 1
hjp=> select f::float8::numeric from t;
╔══════════════════╗
║ f ║
╟──────────────────╢
║ 1.23456788063049 ║
╚══════════════════╝
(1 row)
But those digits aren't the same I stored. So a float4 doesn't "have" 15
decimal digits of accuracy. Not even 8, although in this specific case
the first 8 digits happen to be correct.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
