I think I might have solved the issue by putting SET TIME ZONE ‘UTC’;
into the connection pool init and then at runtime by supplying an OffsetDateTime. But it would be to good to get the OffsetDateTime code generation working, instead of mapping to Object. Can this be done with a converter, or does it require a full binding? > On 8 May 2018, at 13:36, Ben Hood <[email protected]> wrote: > > On Tue, May 8, 2018 at 1:28 PM, Lukas Eder <[email protected]> wrote: >> jOOQ binds TIMESTAMP WITH TIME ZONE to java.time.OffsetDateTime by default. >> >> Domains are currently not supported by the jOOQ code generator. You will >> have to apply a data type rewriting to all relevant columns if you want >> out-of-the-box behaviour. > > Can I do this data type rewriting as an extension point in JOOQ? Or > did you mean something Postgres specific? > >> Why do you need that domain, though? PostgreSQL's TIMESTAMP WITH TIME ZONE >> type is really just a UTC timestamp... The timezone setting is a >> configuration parameter: >> https://www.postgresql.org/docs/current/static/runtime-config-client.html#GUC-TIMEZONE > > Maybe .... the point of the domain was to make it impossible to use a > timezone other than UTC, anywhere, whether via JOOQ or in a proc, ad > hoc script, report or anything. > > You might be right - the motivation was to make timestamps absolutely > bomb proof in the DB. > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
