Re: Domain based on TIMEZONE WITH TIME ZONE

> On 10 May 2018, at 11:36, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:
>
> On Thu, May 10, 2018 at 11:19:36AM +0100, Ben Hood wrote:
>
> I dare say it is one of PG's strengths' to be usable as a
> "linter”.


Interesting that you share this view, because after thinking about why I was doing this, using UTC domains is for PG to
bea linter. 


> However, maybe rephrase to:
>
>     Is it an anti-pattern to use Postgres as a linter for
>     apps that forget to use ... timezones *appropriately* ... ?
>
> As long as you can force apps to submit proper timestamp-with-
> timezone data is there _really_ a need to care whether apps
> do submit in UTC ?

OK, so by using TIMESTAMP WITH TIME ZONE, you force all apps to submit timezone qualified timestamps in what language
theyare written in. 

> After all, it is always converted to UTC
> servside anyway ?

And because of the internal UTC representation, there is no room for ambiguous timezones.

>
> In case you want to enforce only ever _handing out_ UTC data
> you could wrap the table in a view with forces the output
> timezone to UTC and only offers timestamp-withOUT-timezone to
> the outside. Then force read access via the view.

So on balance there is no need to use a domain for this?

Or are we saying that domains are one way of achieving the timestamp hygiene, but equally, you can get the same result
asdescribed above? 

Or is there a specific downside to using a domain for this purpose?

…..maybe I’ve just got a subjective prejudice for using domains to refine and tighten built in data types….