[JAVA] FlightSQL JDBC Driver PreparedStatement#setTimestamp() ignores connection timeStampPrecision
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 48/100
Piste de recherche
Commencez par suivre PreparedStatement#setTimestamp et setTimestamp pour timestamptz jusqu’à DateTimeUtils#sqlTimestampToUnixTimestamp(Timestamp, TimeZone), puis examinez comment l’option de connexion timeStampPrecision est exposée à ce chemin. Reproduisez les exemples de microsecondes et de millisecondes de l’issue et ajoutez ou mettez à jour une couverture ciblée si l’emplacement de test pertinent est identifié. C’est terminé lorsque le serveur reçoit la valeur d’epoch correcte pour chaque précision configurée.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
The FlightSQL JDBC driver always treats timestamps as milliseconds when sending them to the server, ignoring the connection setting timeStampPrecision (for example microseconds). As a result, when the connection precision is set to microseconds the driver truncates/offsets the timestamp and the value stored on the server is incorrect.
Expected behavior When the JDBC connection option timeStampPrecision is set (e.g. microseconds, milliseconds, nanoseconds), PreparedStatement#setTimestamp (and setTimestamp with timestamptz) should send timestamps with the configured precision so the server receives the correct epoch value.
Actual behavior The driver converts java.sql.Timestamp values to an epoch value assuming milliseconds. If the connection is configured for microseconds (or other precision) the conversion is incorrect and inserted timestamps are wrong.
String jdbcUrlFlight = "jdbc:arrow-flight-sql://localhost:9994?useEncryption=0";
try (Connection conn = DriverManager.getConnection(jdbcUrlFlight);
PreparedStatement stmt = conn.prepareStatement("INSERT INTO ... VALUES (?, ?, ?, ?, ?)")) {
for (RowData row : generatedData) {
stmt.setDate(1, row.c_date());
stmt.setTime(2, row.c_time());
stmt.setTime(3, row.c_timetz());
stmt.setTimestamp(4, row.c_timestamp()); // incorrect conversion happens here
stmt.setTimestamp(5, row.c_timestamptz()); // and here
stmt.addBatch();
}
stmt.executeBatch();
}
Example A — timestamp precision in microseconds (bug triggered)
-
Value I want to insert:
- Timestamp object: "2024-11-03 12:45:09.869885001"
- nanos = 869885001
- fastTime = 1730634309000
-
DateTimeUtils#sqlTimestampToUnixTimestamp(Timestamp, TimeZone) returns: 1730637909869:
- Interpreted as milliseconds, that is: 2024-11-03 12:45:09.869 (GMT)
-
Final value inserted into server: 1970-01-21 00:43:57.909869
- Incorrect because the connection used microsecond precision but driver treated the value as milliseconds.
Example B — timestamp precision in milliseconds (works)
-
Value I want to insert:
- "2023-11-29 09:47:32.659534860"
- nanos = 659534860
- fastTime = 1701247652000
-
Driver sends: 1701251252659 (interpreted as milliseconds)
-
Server receives: 2023-11-29 09:47:32.659 — correct when precision is milliseconds.
Environment
- flight-sql-jdbc-driver-18.3.0.jar
- Java: 17
- Server FlightSQL implementation/version: 18.2
- OS: Windows
Relevant code & suspected area
DateTimeUtils#sqlTimestampToUnixTimestamp(Timestamp, TimeZone) appears to be converting timestamps assuming millisecond precision.
public static long sqlTimestampToUnixTimestamp(Timestamp timestamp, TimeZone timeZone) {
long time = timestamp.getTime();
LocalDateTime dateTime = timestamp.toLocalDateTime();
long unixTimestamp = dateTime.toEpochSecond(ZoneOffset.UTC) * 1000L + (long)dateTime.get(ChronoField.MILLI_OF_SECOND);
if (timeZone != null) {
unixTimestamp += (long)timeZone.getOffset(time);
}
unixTimestamp -= (long)DEFAULT_ZONE.getOffset(time);
return unixTimestamp;
}
The driver should respect the connection timeStampPrecision parameter, and correctlyreturn the exact epoch value (as a long) at the configured timestamp precision.
- Langage dominant
- Java
- Étoiles
- 95
- Forks
- 154
- Merge moyen
- 2 j 10 h
- PR mergées (30 j)
- 11
Préparer son environnement
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de apache/arrow-java
-
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
apache/arrow-java#1261 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
apache/arrow-java#1236 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
apache/arrow-java#1230 ·
Les mainteneurs répondent en général sous 1 jour
-
Type: bug
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
apache/arrow-java#1205 ·
Les mainteneurs répondent en général sous 1 jour
-
Type: bug
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
apache/arrow-java#1196 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de apache/arrow-java
Issues similaires
-
TerminalRow.mSpaceUsed (short) overflows on terminals wider than 1023 columns, crashing setCharOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
termux/termux-app#5340 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
apache/rocketmq-dashboard#5110 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 4 jours
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
Les mainteneurs répondent en général sous 1 jour
-
TS2502 in shipped .d.ts: `compileHighlightConfig` parameter shadows the de-aliased `Query` typeOuvertebug javascript
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour