Providing 'Z' for `time` command produces exception (Java)

Describe the bug
I am using 'Z' as fourth argument in the r.time(year, month, day, timezone) command as it is written in the documentation of the time command. After deploying the application to WildFly and triggering the method that has the time method in it I get the following exception:

Exception handling request to ... : org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalArgumentException: Cannot construct instance of `java.util.LinkedHashMap` (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('Z')
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:82)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:346)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:193)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:457)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:245)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:61)
	at org.jboss.resteasy.resteasy-jaxrs@3.12.1.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
	at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
	at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
	at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
	...

So basically this: no String-argument constructor/factory method to deserialize from String value ('Z')

Because 'Z' in not of type String, it is of type char (see here).

To Reproduce
Steps to reproduce the behavior:

I basically use the following code in the method that triggers the exception:

MapObject<Object, Object> date = r.hashMap("date", r.time(2020, 9, 12, 'Z'));
table.insert(date).run(connection);

The method is triggered via a REST call.

Expected behavior
Create the object with 'Z' (char) and with "±[hh]:[mm]" (String) as written in the documentation of the time command and/or correct documentation.

System info

• OS: Ubuntu 18.0.4.5 LTS
• WildFly: 20.0.1.Final
• RethinkDB Version: 2.4.0
• RethinkDB Java driver: 2.4.4

Additional information
The problem is solved as soon as a String is provided, i.e. "Z". So, I suggest changing the documentation of the time command for timezone and/or maybe extend the time command to accept char as argument.

Start with the linked Java time-command documentation and compare its timezone examples with the reproduced r.time(2020, 9, 12, 'Z') call and the stated String workaround. Confirm whether the issue is resolved by correcting the example or requires a driver change; done means the documented Java call matches the accepted argument type and the behavior is clearly explained.