Re: Domain based on TIMEZONE WITH TIME ZONE

> On 10 May 2018, at 11:36, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)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 be a 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 they are 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 as described 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….