On 2020-03-09 16:04, Adriano dos Santos Fernandes wrote:
On 08/03/2020 06:24, Mark Rotteveel wrote:
On 05-03-2020 17:14, Adriano dos Santos Fernandes wrote:
The JDBC specification doesn't support named time zones, only offset
time zones
(OffsetDateTime/OffsetTime),
Please point me to that text.
JDBC 4.2 specification, section 3.1:
"""
* Additional Mappings to Table B-4, Mapping from Java Object to JDBC
Types
[..]
Added support to map java.time.LocalOffsetTime to JDBC
TIME_WITH_TIMEZONE.
Added support to map java.time.LocalOffsetDateTime to JDBC
TIMESTAMP_WITH_TIMEZONE.
* Additional Mappings to Table B-5, Performed by setObject and setNull
between Java Object Types and Target JDBC Types
[..]
Allow conversion of java.time.OffsetTime to CHAR, VARCHAR,
LONGVARCHAR, and TIME_WITH_TIMESTAMP.
Allow conversion of java.time.OffsetDateTime to CHAR, VARCHAR,
LONGVARCHAR, TIME_WITH_TIMESTAMP and TIMESTAMP_WITH_TIMESTAMP.
"""
So, also tables B.4, B.5, B.6 in JDBC 4.2 (and 4.3).
so I must convert to an offset-based data
type.
AFAIK it talks about defaults but support custom mappings.
I'm keeping the option open to support ZonedDateTime in the future, but
as that is not specified by the JDBC specification, those would be a
non-standard extension. And non-standard extensions are just not a good
idea when as a minor JDBC driver, you need to work with tools expecting
standard behaviour.
Also, I'm talking about getDate, for example.
JDBC does not specify a mapping for getDate, getTime, and getTimestamp
for WITH TIME ZONE types (see table B.6). Jaybird does implement it as a
compatibility measure, but I recommend not using it (see also below).
Using the new java.time types is the new standard since Java 8, so usage
of getDate (and getTime and getTimestamp) is discouraged since JDBC 4.2
(in favour of using java.time.LocalDate, java.time.LocalTime and
java.time.LocalDateTime (which are all without time zone information).
The types java.sql.Time, java.sql.Timestamp and java.sql.Date are badly
defined and are historically troublesome, because they are technically a
thin wrapper around epoch milliseconds, while they are specified as the
WITHOUT TIME ZONE value in the JVM default zone (which wreaks all kinds
of havoc with applications in different zones).
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
