Oracle TIMESTAMP in UTC

[Ben Hood]

Hi Lukas,

I'd like to store all timestamps in Oracle in UTC but the app that
receives data from a client should accept timestamps with an offset.

What would be the most appropriate pipeline with JOOQ to ensure that
only UTC is being used internally:

Client -> "2013-06-14T06:32:33.830+05:00" -> ZonedDateTime z; ->
Timestamp.from(z.toInstant()) -> JOOQ DSL -> Database

?

Or is it better to remap the Oracle TIMESTAMP type to a different type
for the generated code, such as Instant or LocalDateTime?

Are there any examples in the documentation where this is covered?

Cheers,

Ben

[Lukas Eder]

Hi Ben,

This, unfortunately, is not yet covered in the jOOQ docs. We wanted to publish full JSR-310 support with jOOQ 3.7, but we ran into several issues that prevented full support. It's rather straightforward to do at the user side, though. You should implement a data type Binding:

http://www.jooq.org/doc/latest/manual/code-generation/custom-data-type-bindings/

... and bind your java.time.Instant type to oracle.sql.TIMESTAMPTZ. As far as I'm aware, the ojdbc driver does not yet support any java.time Types as specified by JDBC 4.2

You shouldn't use java.sql.Timestamp, if possible, unless you can guarantee that the JVM and the Oracle server are both running in UTC. java.sql.Timestamp corresponds to SQL's TIMESTAMP WITHOUT TIME ZONE, or JSR-310's LocalDateTime...

Hope this helps,

Let me know if you have any further questions,

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 jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Hood]

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 :-)

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.

So TIMESTAMPZ is the way to go - what is the advantage of this type?

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?).

Cheers,

Ben

[Ben Hood]

Just following up on the pattern matching for the forced type on
TIMESTAMP(6), after stepping through getConfiguredForcedType(..) I
found that it was better to escape the parenthesis in the code
generator configuration: <types>TIMESTAMP\(6\)</types>

Is this something that is required generally?

[Lukas Eder]

Hi Ben,

Please find comments inline

2015-12-22 15:55 GMT+01:00 Ben Hood <0x6e...@gmail.com>:

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?

[Lukas Eder]

Good point. It's a regular expression. I suspect the manual is wrong here...

Nice catch!

I've created an issue for this:

https://github.com/jOOQ/jOOQ/issues/4840

[Ben Hood]

My initial implementation of this involved the following custom binding:

@Override
public void set(BindingSetStatementContext<ZonedDateTime> ctx) throws
SQLException {
ctx.statement().setTimestamp(ctx.index(), converter.to(ctx.value()), UTC);
}

whereby

public static final Calendar UTC =
Calendar.getInstance(TimeZone.getTimeZone("UTC"));

This appears to insert timestamps into TIMESTAMP(6) columns in UTC
(i.e. the default timestamp type in Oracle).

I'm assuming that the storage of all timestamps in the DB is going to
be in UTC and therefore I don't need to use the TIMESTAMP WITH TIME
ZONE type. Any translation into a non-UTC TZ would have to either be
coded into a query or converted by the app.

The main motivation behind this that I've read (on the internet, hence
it must be true) that there are indexing limitations with the
TIMESTAMP WITH TIME ZONE type.

Maybe this is an unnecessary assumption to make?

Maybe having the explicitness of the TIMESTAMP WITH TIME ZONE
outweighs the downside of having to interpret any timestamp to be in
UTC, which is implicit.

That said, I don't think that the UTC assumption is bad one to have to
make, one just needs to make sure that all ingest paths into the DB
are aware of this assumption.

[Ben Hood]

On Tue, Dec 22, 2015 at 3:29 PM, Lukas Eder <lukas...@gmail.com> wrote:
>> 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?).

This was reference to the parenthesis escaping for regexes in the
generator config - but I see that you've picked this up in a different
thread.

[Lukas Eder]

Hi Ben,

2015-12-22 17:23 GMT+01:00 Ben Hood <0x6e...@gmail.com>:

My initial implementation of this involved the following custom binding:

@Override
public void set(BindingSetStatementContext<ZonedDateTime> ctx) throws
SQLException {
  ctx.statement().setTimestamp(ctx.index(), converter.to(ctx.value()), UTC);
}

whereby

public static final Calendar UTC =
Calendar.getInstance(TimeZone.getTimeZone("UTC"));

This appears to insert timestamps into TIMESTAMP(6) columns in UTC
(i.e. the default timestamp type in Oracle).

I've done some experiments recently and blogged about the results:

http://blog.jooq.org/2015/06/30/whats-even-harder-than-dates-and-timezones-dates-and-timezones-in-sql-jdbc

Ultimately, it is important to know that TIMESTAMP(6) in Oracle is a TIMESTAMP WITHOUT TIME ZONE. I.e. a LocalDateTime. It will produce different UTC timestamps in case your database ever doesn't run in UTC.

Also, the client time zone does affect the real timestamp that is fetched here.

I'm assuming that the storage of all timestamps in the DB is going to
be in UTC and therefore I don't need to use the TIMESTAMP WITH TIME
ZONE type. Any translation into a non-UTC TZ would have to either be
coded into a query or converted by the app.

The main motivation behind this that I've read (on the internet, hence
it must be true) that there are indexing limitations with the
TIMESTAMP WITH TIME ZONE type.

Interesting, I wasn't aware of this. Do you have a link?

 

[Ben Hood]

On Tue, Dec 22, 2015 at 4:53 PM, Lukas Eder <lukas...@gmail.com> wrote:
> Interesting, I wasn't aware of this. Do you have a link?

https://tonyhasler.wordpress.com/2010/09/04/tonys-tirade-against-timestamp-with-time-zone/

This appears to have written in the context of 10g - it's difficult to
tell whether the limitations apply to 12c.

[Ben Hood]

I've made some progress with defining a binding for TIMESTAMPZ <->
Instant but there's one aspect of the code generation I don't seem to
be able to control:

/**
* The column <code>SUBSCRIPTIONS.Z.DATEZ</code>.
*/
public final TableField<ZRecord, Instant> DATEZ = createField("DATEZ",
org.jooq.impl.SQLDataType.TIMESTAMPWITHTIMEZONE.nullable(false), this,
"", new InstantBinding());


The generator correctly sets the type bound for the column, but
somewhere it has a registry that infuses the TIMESTAMPWITHTIMEZONE
type, but the mapping for this is DataType<OffsetDateTime>.

Is there a way to coerce the field to be DateType<Instant> ?

[Ben Hood]

So I've tried to hack something together, but this is literally a hack:

https://gist.github.com/0x6e6562/51b0caf1ebb6d06d1ee2

This seems to work, for some value of work. This means that I can
INSERT and SELECT rows using the custom bindings with generated code.

But I think I'm missing the point on a number of the abstractions -
this feels like a terrible hack, on many levels.

Is there a better way?

[Ben Hood]

On Tue, Dec 22, 2015 at 9:08 PM, Ben Hood <0x6e...@gmail.com> wrote:
> So I've tried to hack something together, but this is literally a hack:
>
> https://gist.github.com/0x6e6562/51b0caf1ebb6d06d1ee2
>
> This seems to work, for some value of work. This means that I can
> INSERT and SELECT rows using the custom bindings with generated code.
>
> But I think I'm missing the point on a number of the abstractions -
> this feels like a terrible hack, on many levels.
>
> Is there a better way?

I've taken a second run up at this problem using OffsetDateTime
instead of Instant. This allows for the offset to be explicit and it
can be down to the application layer to adjust the offset. If the app
doesn't adjust the offset from reason, then the worst that can happen
is that a non-UTC timestamp is stored, but because the offset is also
stored as part of the TIMESTAMP WITH TIME ZONE type, the value is
still explicit and not subject to interpretation.

Here's the example binding code:

https://gist.github.com/0x6e6562/325c0020d1355d28bc08

Note that this still uses the hacked up code generator to merge in the
TIMESTAMPTZ type information, but this is just a POC right now.

The main implementation difference between this variant and the
previous is to defer the packing/unpacking to the routines exposed in
https://github.com/marschall/threeten-jpa rather than using the built
in driver packers. This is because the driver packer from Oracle
appears to shell out the server to grab some ref data in order to pack
and unpack the Oracle native format. But marschall/threeten-jpa
appears to have re-implemented the format as a regular routine. Not
sure whether the server based solution is any less performant, but
unless the driver is caching the lookups, this might result in a bunch
of network round trips. I assume without any evidence to back this up
that the reason why the driver takes this approach is to handle the
case when the zone map ref data is updated on the server.

Note that this approach also links directly to the Oracle library,
which means it's a non-portable and non-restributable solution.

Having said all of this, am I potentially over thinking the whole problem?

[Lukas Eder]

Hi Ben,

I'm sorry for the delay in this matter.

It is true that binding the Oracle TIMESTAMP WITH TIME ZONE data type brings a couple of caveats. Unfortunately, I cannot tell you from experience what will happen, perfomance-wise, if you use one solution rather than the other. I can, however, confirm that what you feel is a bit hacky might just be as good as it gets right now. I've reviewed other customers' Binding implementations that attempt to bind the java.sql.SQLXML type, which needs to be free'd explicitly via SQLXML.free() after statement execution (similar to Blob, Clob). Things start getting just as hairy.

Usually, with these exotic types, people are happy if they can just serialize / deserialize them to / from the server (e.g. XML). In your case, I agree that there is significant concern regarding runtime performance, but unfortunately, I'm as wise as you are right now.

One approach that I've seen in the past is people storing just java.lang.Long values for what corresponds to java.time.Instant. As long as you don't need any date time arithmetic in the database, this might be enough, and is certainly not a performance issue.

Another option might be to implement a Binding that completely ignores the serialisation of the TIMESTAMP WITH TIME ZONE type, binds (and reads) java.lang.Long, and converts the number into a timestamp by generating some additional SQL, e.g. as explained here:

http://stackoverflow.com/a/15520654/521799

Hope this helps.

Let me know if, in the meantime, you have any additional questions.

Best Regards,

Lukas

[Ben Hood]

Hi Lukas,

Sorry for the radio silence - I've been busy chasing down timezone
issues with the reports that are built off the back of this app.

Thanks for the alternative routes that you've suggested.

Unfortunately my app does a lot of date time arithmetic in the data
base, i.e. making heavy use of TRUNC(DATE), EXTRACT(MONTH AT TIME ZONE
x), MULTISET CONNECT BY ADD_MONTHS(), LAST_DAY() as well as storing
in UTC but rolling up in user defined timezones.

But I've managed to get JOOQ to fire off OffsetDateTime instances down
to the DB thusly:

final static DateTimeFormatter DATE_TIME_FORMATTER =
DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSZZZ");

static Field<OffsetDateTime> format(OffsetDateTime odt) {
Object value = (odt == null) ? val(null) : odt.format(DATE_TIME_FORMATTER);
return field("{to_timestamp_tz}({0}, {1})", OffsetDateTime.class,
value, "YYYY-MM-DD\"T\"HH24:MI:SS.ff3 TZH:TZM");
}

Maybe there is a more elegant way to do this, but it seems to work and
I've got rid of masses of timezone bugs.

That said, I've now just started to programmatically read from the DB
and I've run into a read issue with JOOQ (whereas the previous part of
this thread was dealing with the write path) and I'm getting the
following issue:

java.time.format.DateTimeParseException: Text '2014-04-01T10:11:10.15
+0:00' could not be parsed at index 22
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
at java.time.OffsetDateTime.parse(OffsetDateTime.java:402)
at java.time.OffsetDateTime.parse(OffsetDateTime.java:387)
at org.jooq.impl.DefaultBinding.offsetDateTime(DefaultBinding.java:1496)
at org.jooq.impl.DefaultBinding.get(DefaultBinding.java:1336)
at org.jooq.impl.CursorImpl$CursorIterator$CursorRecordInitialiser.setValue(CursorImpl.java:1640)

The offending code that causes this is:

Cursor<Record1<OffsetDateTime>> cursor =
ctx.select(CDR_IDENTIFIERS.EFFECTIVE).from(CDR_IDENTIFIERS).fetchLazy();
while (cursor.hasNext()) {
// BOOM!
}

Is a way to register a Converter instance via the DSL API in order to
override the default Converter? Or is this only possible with code
gen?

Cheers,

Ben

[Ben Hood]

On Wed, Jan 13, 2016 at 12:33 AM, Ben Hood <0x6e...@gmail.com> wrote:
> java.time.format.DateTimeParseException: Text '2014-04-01T10:11:10.15
> +0:00' could not be parsed at index 22
> at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.OffsetDateTime.parse(OffsetDateTime.java:402)
> at java.time.OffsetDateTime.parse(OffsetDateTime.java:387)
> at org.jooq.impl.DefaultBinding.offsetDateTime(DefaultBinding.java:1496)
> at org.jooq.impl.DefaultBinding.get(DefaultBinding.java:1336)
> at org.jooq.impl.CursorImpl$CursorIterator$CursorRecordInitialiser.setValue(CursorImpl.java:1640)

I ended up solving this issue by getting JOOQ to build the SQL and
JDBC to execute and deserialize the data:

db.executeVoid(ctx -> {

String query = ctx.
select(CDR_IDENTIFIERS.EFFECTIVE).
from(CDR_IDENTIFIERS).
getSQL();

ctx.connection(c -> {
PreparedStatement ops = c.prepareStatement(query);
ResultSet rs = ops.executeQuery();
while (rs.next()) {
TIMESTAMPTZ ts = rs.getObject(1, TIMESTAMPTZ.class);
OffsetDateTime odt = converter.from(ts);
// do something with this data
}
});

// do other stuff in the same TX with the JOOQ DSL

});

[Lukas Eder]

Hi Ben,

Thanks for your E-Mails and for the workaround. Yes, once you can access your ojdbc Connection, there's always a way to directly interact with the JDBC API.

Ideally, though, you would be writing a data type Binding (http://www.jooq.org/doc/latest/manual/sql-building/queryparts/custom-bindings/), and associate that with your CDR_IDENTIFIERS.EFFECTIVE column. You could then move the rs.getObject(index, TIMESTAMPTZ.class) call into the binding, and it would work for all references of the EFFECTIVE column.

have you tried that?

Best Regards,

Lukas

[Lukas Eder]

Hmm, one more thought about your exception. I've overlooked a detail:

java.time.format.DateTimeParseException: Text '2014-04-01T10:11:10.15
+0:00' could not be parsed at index 22
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
at java.time.OffsetDateTime.parse(OffsetDateTime.java:402)
at java.time.OffsetDateTime.parse(OffsetDateTime.java:387)
at org.jooq.impl.DefaultBinding.offsetDateTime(DefaultBinding.java:1496)
at org.jooq.impl.DefaultBinding.get(DefaultBinding.java:1336)
at org.jooq.impl.CursorImpl$CursorIterator$CursorRecordInitialiser.setValue(CursorImpl.java:1640)

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

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.

Best,

Lukas

[Ben Hood]

Hi Lukas,

On Thu, Jan 21, 2016 at 3:17 PM, Lukas Eder <lukas...@gmail.com> wrote:
> Ideally, though, you would be writing a data type Binding
> (http://www.jooq.org/doc/latest/manual/sql-building/queryparts/custom-bindings/),
> and associate that with your CDR_IDENTIFIERS.EFFECTIVE column. You could
> then move the rs.getObject(index, TIMESTAMPTZ.class) call into the binding,
> and it would work for all references of the EFFECTIVE column.
>
> have you tried that?

Is that something different to the code from the gist that I linked to
earlier in the thread?

For note I'm using this in my generator config:

<customType>
<name>OffsetDateTime</name>
<type>java.time.OffsetDateTime</type>
<binding>com.acme.bindings.OffsetBinding</binding>
<converter>com.acme.bindings.OffsetConverter</converter>
</customType>

Or did you mean something different?

Ben

[Ben Hood]

On Thu, Jan 21, 2016 at 3:26 PM, Lukas Eder <lukas...@gmail.com> 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 :-(

>
> 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.

[Lukas Eder]

I'm sorry I must have missed the binding before. That's what I meant. 

[Lukas Eder]

2016-01-26 19:49 GMT+01:00 Ben Hood <0x6e...@gmail.com>:

On Thu, Jan 21, 2016 at 3:26 PM, Lukas Eder <lukas...@gmail.com> 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

[Ben Hood]

On Thu, Jan 28, 2016 at 5:07 PM, Lukas Eder <lukas...@gmail.com> wrote:
> 2016-01-26 19:49 GMT+01:00 Ben Hood <0x6e...@gmail.com>:
> 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 :)

Do you think that Block Chain DBs can handle DST? And if so, when is
JOOQ going to bind to them?

> 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).

Interestingly enough, I was speaking to one of the Scala compiler guys
years ago who was telling me that polymorphic dispatch was implemented
quite efficiently in the JVM.

[Lukas Eder]

2016-02-01 17:42 GMT+01:00 Ben Hood <0x6e...@gmail.com>:

On Thu, Jan 28, 2016 at 5:07 PM, Lukas Eder <lukas...@gmail.com> wrote:
> 2016-01-26 19:49 GMT+01:00 Ben Hood <0x6e...@gmail.com>:
> 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 :)

Do you think that Block Chain DBs can handle DST? And if so, when is
JOOQ going to bind to them?

;-)

 

> 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).

Interestingly enough, I was speaking to one of the Scala compiler guys
years ago who was telling me that polymorphic dispatch was implemented
quite efficiently in the JVM.

It is. But it can bite you as well (in hot loops):

http://shipilev.net/blog/2015/black-magic-method-dispatch

Although, not as bad as large if-else blocks.