2016-01-26 19:49 GMT+01:00 Ben Hood <[email protected]>:
> On Thu, Jan 21, 2016 at 3:26 PM, Lukas Eder <[email protected]> wrote:
> > The issue here seems to be related to the fact that the offset is of the
> > form +0:00 rather than +00:00. It's a shame that JSR 310 parsing is so
> > strict, but we can certainly work around this issue in jOOQ. I have
> > registered #4965 for this:
> > https://github.com/jOOQ/jOOQ/issues/4965
>
> If I tried tried to calculate the percentage of my career that I've
> spent fixing time zone issues, that code itself would most likely have
> a date/time arithmetic bug in it :-(
>
Same here. :) The weirdest bug I've ever encountered was a single missing
bank account transaction for only a single customer in only a single
E-Document, and only on October 31, 2010. Turns out that transactions were
searched using the following predicate (pseudo code):
TRANSACTION_DATE BETWEEN TRUNC(beginning of month) AND TRUNC(end of
month + 24 * 60 * 60 * 1000 milliseconds)
Turns out that in Switzerland, 2010-10-31 had 25 hours (daylight savings
time), and because it's a Sunday, no one noticed as there are hardly any
bank account transactions on Sundays :)
> > Thanks again for reporting all of these things. I wish jOOQ could already
> > offer more out-of-the-box help here with these data types. It shouldn't
> be
> > so hard to integrate them as it is, right now.
>
> I think the holy grail API-wise would be to have a greater ability to
> tweak/override the default bindings when one comes across this kind of
> thing. That said, I not sure what the right API design should be. If
> you expose stuff such that people can subclass default
> implementations, I can imagine that you will find yourself having to
> break more apps as you evolve the default libraries. Tricky.
>
You're right. The DefaultBinding inherited a bit of legacy. Its procedural
if-else blocks are also a performance issue. The method is too large to be
inlined by the JIT, plus after a couple of branches, if-else tends to be
slower than dynamic dispatch (https://github.com/jOOQ/jOOQ/issues/4930).
Which means, there will soon be a Binding per data type. Subtyping that for
further extension might then be an option, indeed, but it's tricky as there
are always corner cases with data types and SQL dialects.
Best Regards,
Lukas
--
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.
