Hi Ben, Please find comments inline
2015-12-22 15:55 GMT+01:00 Ben Hood <[email protected]>: > Hi Lukas, > > Thanks for the heads up. I can appreciate that the subject of date > handling is very tricky to get right at a generic library level to > suit all use cases. I'm struggling enough with dates in just one app, > let alone any arbitrary app :-) > It's probably THE most tricky topic. Unfortunately. > I've already run into the issue of the timezone of the JVM app - > previously I had a JOOQ Timestamp <-> ZonedDateTime Converter, but > discovered that the resultant Timestamp was in the JVM timezone, i.e. > the conversion was lossy and dependent on the JVM setting. I'd prefer > the code base to be independent of the JVM time zone, since relying on > a bug-free JVM setting is asking for trouble IMHO. > I agree. > So TIMESTAMPZ is the way to go - what is the advantage of this type? > This type is capable of modelling the time zone that is associated with your Instant (e.g. UTC): http://docs.oracle.com/cd/E11882_01/appdev.112/e13995/oracle/sql/TIMESTAMPTZ.html I'm assuming that you plan to store the time stamp as TIMESTAMP WITH TIME ZONE in Oracle, which corresponds to ZonedDateTime (in Oracle). In PostgreSQL, it would correspond to Instant. > BTW I think I'm still struggling with the match specification for the > forced type in the code generator. Previously I started a thread about > this with regard to NUMBER(19) and how to debug this, which I have > deferred up until now, but now I think I'll have to bite the bullet. I > think that forced type handling code is an util class that is not > ordinarily on the project classpath (because it is compiler-related > code?). > Not sure what you mean by this? -- 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.
