On 2021-09-21 13:43:46 -0400, Dave Cramer wrote: > > > On Tue, 21 Sept 2021 at 13:40, Peter J. Holzer <[email protected]> wrote: > > On 2021-09-21 13:34:21 -0400, Dave Cramer wrote: > > On Tue, 21 Sept 2021 at 13:20, Peter J. Holzer <[email protected]> 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.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
