Re: Storage sizes for dates/times (documentation bug?) - Mailing list pgsql-general

From Karsten Hilbert
Subject Re: Storage sizes for dates/times (documentation bug?)
Date
Msg-id 20080416194045.GB7478@merkur.hilbert.loc
Whole thread Raw
In response to Re: Storage sizes for dates/times (documentation bug?)  (Sam Mason <sam@samason.me.uk>)
List pgsql-general
On Wed, Apr 16, 2008 at 08:21:15PM +0100, Sam Mason wrote:

> Hum, what's an "EMR"?

Sorry, Electronic Medical Record.

> Why not do:
>
>   CREATE TYPE tstz AS ( ts TIMESTAMP WITH TIME ZONE, tz TEXT );
>
> And use this instead?
That should work. At the time (a couple of years ago) I
wasn't aware of all the implications. Indexability, operator
availability, computability ...  I'm still not sure I'd know
all the pitfalls.

> What sort of machines do this?  With computers I've used, if its time
> zone is set to the local time of some specific location then yes it
> will.  If you set it to some specific offset then no it won't.  These
> are independant cases, and not the one I was drawing your attention to
> above.  These cases are also independant of the original problem as
> well.
All true. I misunderstood what you said.

> > Basically, akin to "there's no such thing as plain text"
> > there should be "there's no such thing as a timezone-less
> > timestamp".
> Or maybe, a programming language should allow you to define your own
> abstractions if the defaults don't fit.
Surely so and both Python and PostgreSQL have both been very
helpful in this regard.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: "vacuum" and "cluster"
Next
From: "Richard Broersma"
Date:
Subject: ALTER TABLE DDL Triggers?